Attending: Brian, Dan, Winnie, PeteC, Teng, Jens (chair+mins), Matt, Duncan, Sam 0. Op. B. P. Matt reported a problem with the SRM being overloaded, so he asked ATLAS to switch to xroot instead. However, jobs then fail to write their data at the end because they somehow did not get the memo? and they finish their rather long calculation and fail. This seems to be for both reads and writes (with the job writing at the end obvs). These are production jobs but that is just because Lancs happen to be running production jobs for ATLAS. Teng reports that AGIS can be configured to use xrdcp only; and Brian says it's possible to separate read and write protocols, but points out that a change will (probably) not affect existing pilots. It will be necessary (and useful) to test LAN access to a DPM with no SRM. 1. DOME (otherwise) No (other) news. 2. EOS Edinburgh - no news. RAL's CERN data lake - should be able to give access to GridPP VO... Incidentally, why is ALICE keen on EOS? They want a "single SE" solution philosophy whereas that of the grid is that you should not care about which implementation you are talking to, as long as all SEs provide compatible and interoperable interfaces. Maybe useful to think of ALICE as nuclear physics rather than particle... anyway, if they're happy with the Birmingham EOS then we're OK. 3. Do we have a "data transfer solution" other than "rsync and Globus"? We're using FTS and DiRAC is using FTS and Rucio uses FTS. The general users would (probably) need a CLI, Web/portal, and API interfaces to data access and transfer. Admittedly a vague use case - but it's as much about knowing what we've got when the next user community comes along, and a less GridPP-y one and a more IRIS-y one. Pete suggests it is worth working with the more technical user communities like EUCLID and SKA who can devote some effort to the integration. Probably worth starting at a low level, and not put too much effort into it till we have a more specific use case. It would also be useful to know what data rates we can get in practice. Much of this is an AAI issue: if you want browser access, you (currently) need a certificate in the browser (unless data is World readable), and browsers don't handle VOMS extensions/proxies well, so you'd need a conventional certificate which means the server must have a gridmap file. Conversely, if you want federated login, then you usually have to get this through a browser, and then get a token or something to paste into a command line or script (a scitoken/JWT, OAuth token, MyProxy password, or whatever.) On the third hand, if you want to transparently get a certificate, you'd probably need something like RCauth [or Pathfinder with Assent.] None of these are straight-out-of- the-box solutions at this stage and will require effort. 4. AOB Dan mentions two things. First, there is a StoRM with 3rd party copying on WebDAV. (on a related note Alessandra will be presenting DOMA TPC in today's GDB, https://indico.cern.ch/event/651359/) Secondly, there is an issue with LHCb files where path names have two slashes int them. Paige I don't hear anything are you speaking PW Yes, Matt's speaking Brian http://atlas-agis.cern.ch/agis/service/detail/18071/ BD Teng http://atlas-agis.cern.ch/agis/pandaqueue/detail/UKI-SCOTGRID-ECDF_MCORE_SL7/full/ T Samuel Okay, that was weird, my laptop just restarted twice when trying to connect to the meeting! SC Teng under the Associated Pilot Copytools (sitemovers) remove rucio and use xrdcp only T Daniel ;) DP Duncan Yes, start with use cases DR The current AAI draft talks about sharing research data in a v. high level Brian Or questions like., is your data in files that are immutable? BD Duncan https://peerj.com/articles/cs-144/ The Modern Research Data Portal: a design pattern for networked, data-intensive science DR Thanks Daniel https://indico.cern.ch/event/764679/contributions/3190439/attachments/1741251/2817259/StoRM_TPC_support_update.pdf https://ggus.eu/index.php?mode=ticket_info&ticket_id=138292 DP Today at 10:40 AM