Attending: Jens (chair+mins), Winnie, Ewan, Robert, Raja, special guest star Shaun, Steve, Matt D, Govind, Tom, John B, Rob, Sam, Elena, Raul. 1. Shaun gave a presentation of the SAGE project which is led by Seagate. It aims to develop HSM for HPC involving something like five layers of storage, e.g. tape, slow disk, fast disk, cache, RAM, special "exotic" RAM, etc. STFC's involvement includes examining object store vs CEPH and SWIFT, and bringing in a use case of managing data from Diamond light source and CCFE (aka Culham). SAGE itself will not be available at STFC; it will be run at Juelich and access to it will be restricted to project partners. There will be an investigation into migration policies; Seagate will lead this. Note that much of the output is confidential, and the plans for "exotic RAM" are under NDA, so we are not allowed to know about it... the project is funded under the future and emerging tech, so is allowed to keep some of the commercial stuff it is developing. The system will be accessed using NFS, basing it on Ganesha, a user space NFS4 project. The SWIFT API is also considered "interesting", being pseudo hierarchical, ie supporting '/' in object names to provide some kind of wildcardy pathy functionality [ ie reinventing SRM 1 :-) ]. Sam is also slightly interested in the SWIFT API. It has more support than CDMI at the moment, and is like CDMI open, although CDMI is more standardised having gone through interoperation etc. Other random questions for Shaun: time scale for CEPH deployment at RAL? Shaun would guesstimate preprod ~ Aug, and prod ~ Dec. There has, or will be, or may be, some changes in leadership in the team. Shaun says the GridFTP server for CEPH is "75-80% working". SRM 2.1.4? [This is the CASTOR SRM version number, not an exotic version of the SRM2 protocol.] - currently going through change control, will need more testing on preprod, expecting seamless upgrade. 0. Operational blog posts - still only three blog posts for this quarter?! 2. Small VOs. LIGO is trying to use the DIRAC IC endpoint; there is a ticket raised by Sam (see chat log) against IC. GridPP DIRAC is still very testing-y, needs to be more production-y before we can really recommend it to VOs. LIGO are still using SouthGrid as their VO, which has the advantage that they can fairly easily get started and do stuff, instead of waiting weeks for the VO to be set up and more weeks for resources to be allocated to it. OTOH, there may then be some migration needed once they have their real VO. In Pete's current spreadsheet with VO allocations, it may help in the future to have a real name for the VO (even just for accounting purposes). It may also help with the accounting/quotaing which Steve reported, where one VO consumes more than its fair share of a common storage space. And of course it helps with other things like access controls for VO members and finding tickets in GGUS etc. It also shows that it is easier for us to help debug stuff - as both Ewan and Jens have pointed out recently - if we, in GridPP - are members of the VOs. We are obviously able to be members of the GridPP VO, so we can help those that use the GridPP VO initially, so this is another good case for using the GridPP VO initially, but it may be useful also when the VO grows up and becomes its own VO as we have seen with DiRAC. As an aside, we can generally be members of more than one VO; it works fine because mostly we need to assert only the VOMS magic. Only for CASTOR is it a problem. For web access it may also be a problem because browsers do not generally hold VOMS-blessed proxies for users, but Ewan points out that most resources will let you select the VO (within the ones you are member of), and it works fine. Apropos DiRAC, currently debugging the GridFTP transfers - seems to be a firewall issue. Jens moved discussion to dirac-users on jiscmail to ensure that the accumulated wisdom is preserved because eventually we will be adding more sites and having the archives of the problems and solutions will help. UKQCD - Craig had been trying to use a grid UI, but they had changed since last time he had been using one. Not yet started on DIRAC, so will be using low level tools, but they have changed, e.g. GFAL2 instead of GFAL, etc. Also the information system (aka BDII) generally helps. It caused a bit of confusion for SNO+ on CASTOR as they found an undefined path - it was on closer inspection pointing correctly to the disk scratch space used by ops, whereas the tape area that they should be using was correctly publishing the path to the tape, but it may look confusing if you only use the lcg-info. CASTOR publishes the SAPath if all the VOInfo paths associated with the SA are the same, otherwise the SAPath is set to undefined. 3. Last week's GDB There were things on dCache and preservation of data, but not something we need to discuss here, people can read it if interested and there will be a bit more news on preservation within one of the coming weeeks. 4. AOB Sam - deployment task force has come out with "streamlined" recommendations, see link in chat. Ewan - case for wider use of backups into Tier 1, like the DiRAC stuff we are (nearly!) doing at the moment; also the Sussex backup we discussed. If not using GridPP, RAL has another tape robot for non-GridPP... Paige Winslowe Lacesso: (17/06/2015 10:00:26) Howy! s/Howy/Howdy!/ Raja Nandakumar: (10:09 AM) What is the spelling? Sage? Is there a web page? Yes :) Ewan Mac Mahon: (10:17 AM) Like SRM Matt Doidge: (10:23 AM) nutella on weetabix might be quite tasty. Samuel Cadellin Skipsey: (10:27 AM) https://ggus.eu/index.php?mode=ticket_info&ticket_id=114379 Ewan Mac Mahon: (10:28 AM) You should though, we're lovely :-) Raja Nandakumar: (10:29 AM) Apologies - got to go now Tom Whyntie: (10:30 AM) Yes, that's a good point the SE listing should only list those available to the user Yup, you just need to ask Janusz to add you to the VO I'm cernatschool_user, gridpp_user and londongrid_user @Ewan It is Jens Jensen: (10:32 AM) It's only CASTOR which has trouble with people being in more than one vo... Ewan Mac Mahon: (10:34 AM) We should spacetoken them. Samuel Cadellin Skipsey: (10:34 AM) https://ggus.eu/index.php?mode=ticket_info&ticket_id=114248 is Steve's ticket Ewan Mac Mahon: (10:34 AM) Which is easier said than done, but it's what we've got. John Bland: (10:35 AM) it's 100s of GB so far, but constant Ewan Mac Mahon: (10:40 AM) And speaking of lists we should shunt the LIGO discussions across to gridpp-support. Matt Doidge: (10:41 AM) I'm sure we've discussed this many times before - could we policy it so that if a VO uses more the a few hundred GB it has to go into a spacetoken? John Bland: (10:41 AM) Spacetokens: All VOs, All the time. IMO. Ewan Mac Mahon: (10:43 AM) The downside for us of spacetokens is that they're a reservation, so if you reserve (say) a couple of TB each for twenty little VOs that never use it you're still out a 40TB server for nothing, Samuel Cadellin Skipsey: (10:44 AM) And they need to be explicitly used. Ewan Mac Mahon: (10:44 AM) But possibly the solution to that is simply "don't do that then" an just give people really, really tiny tokens until there's something in them. That's a downside for the users :-) Samuel Cadellin Skipsey: (10:44 AM) (and they aren't quotas, as Ewan notes) John Bland: (10:44 AM) until all SEs support quotas, we'll have to lump it Ewan Mac Mahon: (10:44 AM) But it would be nice to have the implicit path based spacetokening thing, and we're sort-of going to have to for non SRM interfaces anyway. (I'd have thought0 John Bland: (10:45 AM) STs are a pain in the ass, but still better than letting users run riot in your shared storage Samuel Cadellin Skipsey: (10:46 AM) https://twiki.cern.ch/twiki/bin/view/LCG/HTTPTFStorageRecommendations