Attending: Elena, John H, John B, Raja, Steve, Wahid, Jens (c+m), Tom, Brian, David, Sam, Ewan, Matt RB 0. Operational issues - and blog posts!! 1. Post-workshop - highlights, new stuff & things on the horizon, and other exciting things? Some discussion about possible replacements for SRM, or alternatives (again), a discussion not dissimilar to previous discussions we have had before and revisited earlier. One of the main things is space tokens but it may be possible to implement them by other means, e.g. a specified directory path - but it would be implementation specific, and clients would need to know which flavour of SRM they talk to. The original purpose of SRM was to have a single control interface which would be published by all SEs, and would enable the negotiation of transfer protocols, as well as (for tape systems) requests that files be staged, etc. The storage evolution technical group looked at which features of SRM were being used. ATLAS is using SRM for space reporting and deletions. There is, however, a plan to move away, using RUCIO. If we implement non-SRM "solutions", will there be time to have them in place and adapted before Run 2? Also of interest was the ATLAS data model with (currently) beam down, which is expected to not alter much in terms of workload and processes for beam up, so what we do at the moment to make things better will also be relevant for Run 2. ALICE: "all storage in EOS"... (??) "EOS for CERN but not for small sites" EOS is CERN specific and there is some merit in using instead other products which were not (re)implemented by CERN, but are instead readily available off the shelf. LHCb: will need "healthy chunks of storage", also at T2s (ie the usual ones, Manchester and RALPP) Will need funding for O(1)*100TB. Other things: H2020 projects (proposals) on data-related stuff, like EU-T0 (Zephyr). Would a T0 sound too HEP-specific, scaring off non-HEP? Or more generally, the names that we choose... 2. Update on WebFTS? 3. AOB Jens: (16/07/2014 10:04:37) http://indico.cern.ch/event/305362/ http://indico.cern.ch/event/305362/other-view?view=standard Ewan Mac Mahon: (10:10 AM) It's going to need grid cert bits if nothing else. wahid: (10:11 AM) well not (maybe) if I get my world readable goal Ewan Mac Mahon: (10:11 AM) It's still going to need grid cert bits unless you want it world writable too. wahid: (10:12 AM) yes - thats why I put the maybe you could have a gridftp data mover door not difficult Ewan Mac Mahon: (10:13 AM) Isn't this protocol problem essentially covered by URLs? You can tell what you need to use to talk to xroot:// and for https:// And an SRM client already needs to be multiprotocol anyway because SRM already hands off to one of the transfer protocols. Jens: (10:14 AM) In theory that's in the inforamtion system too (but would then create a cacheable dependency on the information system) Samuel Cadellin Skipsey: (10:14 AM) The point, Ewan, is more that SRM provides a guaranteed way to discover protocols etc and negotiate them. Ewan Mac Mahon: (10:17 AM) Maybe we need an automated interface that allows site services to add information about themselves into AGIS :-P I do think there's a general move towards shiny new hotness because it's fun. Which it is. Samuel Cadellin Skipsey: (10:23 AM) sure: but also, because actually "modern" in this sense is as old as 2005 And S3 is hardly a new protocol. (remember, Amazon S3 launched in 2006... *before* the LCG was completely commissioned) Ewan Mac Mahon: (10:26 AM) If ALICE want all their storage on EOS they can just ship everything back to CERN. Samuel Cadellin Skipsey: (10:27 AM) Well, the response from the room at WLCG Workshop was... not positive. Ewan Mac Mahon: (10:27 AM) Which might actually work for them. Looping back round; S3 supports bittorrent, which ALICE used to use for something. Samuel Cadellin Skipsey: (10:28 AM) I think ALICE used bittorrent for their equivalent of DBRelease files? Jens: (10:29 AM) :-) Ewan Mac Mahon: (10:29 AM) I believe we were all calling it NIHfs when they first announced it. wahid: (10:31 AM) we are aren't we Ewan Mac Mahon: (10:34 AM) Is this basically PRACE for disks? Tom Whyntie: (10:38 AM) The other nice thing about the "long tail" is that requirements seem to be pretty small too... wahid: (10:39 AM) also every time i type voms-proxy-init it seems to give me a different confusing error message.. and I type it many times a day Ewan Mac Mahon: (10:40 AM) Proxies are great though. wahid: (10:40 AM) whereas cern single sign on for the web I really just do once .. and eduroam I don't do anything Ewan Mac Mahon: (10:40 AM) They allow you to send something off that proves it's you without it being horribly insecure. The key is the delegatability. Samuel Cadellin Skipsey: (10:41 AM) ...but they are inherently insecure, Ewan Ewan Mac Mahon: (10:41 AM) Proving you're you is easy. Proving that a job is working on your behalf is tricky, Samuel Cadellin Skipsey: (10:41 AM) A proxy *is* a delegated, unlimited, token that allows the owner to act as you. (for a limited time) That subverts the entire point of public/private key cryptographic security. Ewan Mac Mahon: (10:42 AM) And they have limits too don't they? I'm sure I recall something about proxies on WNs not being allowed to submit new jobs. Samuel Cadellin Skipsey: (10:42 AM) But they can do anything they want to your data. (and if you get a proxy off a WN, you can submit new jobs happily from the UI you own) Ewan Mac Mahon: (10:43 AM) We actually need something that allow a job that isn't me to operate on my behalf. That's kindof the entire point. Samuel Cadellin Skipsey: (10:43 AM) *and* their lifetime is subverted by MyProxy servers, which are basically a way to turn X509 security into a password auth Ewan: easy, signed code + certificates Solved. Solved in the 1990s, at the latest, in fact. Ewan Mac Mahon: (10:45 AM) Hmm. I can see that for the job side, so I'll run your signed job, but how does your signed job then access someone else's storage over the network?