Attending: Elena, Ewan, John H, Matt D, Winnie, Tom, Wahid, Jens (chair+mins), John B, Chris B, Robert, Steve, Gareth, Sam, Brian, David, Jeremy, Govind 0. Still only two blog posts! Operational issues: Dan at QMUL is in downtime. 1. Moving stuff forward: DIRAC, DiRAC, EGI. EUDAT? While much of the DIRAC stuff is "just" a front end to normal stuff - SEs aren't different - there may be a need for us to understand things like file catalogues, data clients and data movement, catalogue synchronisation, etc. Sam has some experience with DIRAC's data tools, and found them flakey... The catalogue looks like LFC. There are some counterintuitive things, like having global attribute names (metadata keys) LHCb already have a DFC consistency checker. Whom are we aiming to support, sites or users? While our focus is definitely primarily on sites - ie providing storage which is suitable also for use with DIRAC, particularly if LHCb starts using more T2s, and other VOs start using DIRAC - anyway, our focus in on sites providing suitable and adequate storage. However, GridPP people sometimes end up providing some kind of support for local users, and information to new prospective users, particularly from local groups. If DIRAC is to be a more attractive option for them, it would make sense that we know a bit more about it. Could also ask Dan from NA62. Regarding DiRAC, Jens had been talking to Stephen Booth from EPCC (most recently in January) regarding how GridPP and DiRAC might interoperate, particularly in the case of identity management - maybe via SARoNGS, and perhaps job submission would be a lower hanging fruit than data interoperation. Jeremy mentioned a proposal to provide 5PB backup storage, but that would be more at the 'robot' level rather than individual VOs' or users' activities. Jens is involved at some level with both EGI federated cloud and EUDAT (soon to be EUDAT2020), which also have storage related components (CDMI and B2SAFE respectively). Given our loosely coupled modus operandi, what is the best way to progress actions - given that waiting for someone to have enough spare time to progress something is probably not hugely helpful. But most of these additional activities are lower priority - the day to day activities of running and supporting storage systems will almost always have to take precedence. 2. Round table of activities and issues - a semi-irregular chance for people who don't normally say much to say something! Something storage related, that is. Postponed to next week - in the interest of time. 2. Storage outside firewalls Govind had a use case for putting storage outside firewalls, and since lots of sites have this, he asked for suggestions and recommendations. One obvious thing is that you have to convince site IT security, and also make a case that it is worth it by demonstrating that you get higher transfer rates outside the firewall - or that you make life miserable for others by transferring data through their firewall.... Jeremy points out this was also discussed at an ops meeting ~6 months ago, and offers to locate the link. Just iptablesing the host would not be sufficient, and an intruder, once inside, can easily take down iptables. While the host is not intended to be broken into :-) - or even logged into, we also tend to patch local exploits. Also complicating matters is that GridFTP needs large and strange port ranges. And also consider the backend database. Firewalls also create their own set of problems which can be very hard to debug. We should try to create a page and a checklist. [Update: Jeremy found the following information: https://indico.cern.ch/event/349676/ There were also some more detailed writeups from the meeting which are not public? but should feed into the recommendations. 3. AOB Tom Whyntie: (25/02/2015 10:00:14) Mornin' Apologies in advance - I can only stay for 30 minutes. https://www.gridpp.ac.uk/wiki/DIRAC_new_user_checklist Ewan Mac Mahon: (10:20 AM) I wouldn't bank on getting anything interesting done at Cambridge. Jeremy Coles: (10:21 AM) Why? Ewan Mac Mahon: (10:21 AM) John's fine running a production site, but he doesn't seem to have a lot of time on his hands for exciting new things. e.g. see yesterday's IPv6 discussion. That might sound more critical that I meant it to; I think Cambridge is a fine site, but it's not one with a lot of GridPP effort. Getting people to work with Oxford/Glasgow/Manchester/ECDF etc. is probably a better bet. John Hill: (10:23 AM) That's OK Ewan, I understood what you meant Ewan Mac Mahon: (10:24 AM) Thanks; nuance in text can be tricky :-) wahid: (10:28 AM) Surely they are the example of exactly what Tom is talking about - a pointless thing on the Q report the problem is 'blog posts ' is a bannas metric for a storage group Matt Doidge: (10:30 AM) We always research in montages at Lancaster. Jeremy Coles: (10:30 AM) Took a call and missed some discussion! Wahid - what metrics would you suggest? We should build up ideas before someone else sets them for GridPP5. wahid: (10:31 AM) storage availabilty Jeremy Coles: (10:32 AM) The experiments do that in their reports. wahid: (10:32 AM) ok - so nothing needed then Tom Whyntie: (10:32 AM) Have to go - thanks for the discussion, TW wahid: (10:33 AM) dont need to make up some pointless and counter productive metric for the sake of it. Ewan Mac Mahon: (10:33 AM) It's not an unreasonable assumption that someone will have done something interesting, and when they have there is value in its being blogged. The metric only really falls down when there are no posts because nothing interesting's been done, but that is not the comon case. wahid: (10:33 AM) value maybe - but its not the number one important issue for the group. anyway we discussed this many times. others seems to think if its of crucial importance to write blogs so they should go ahead and do so.. Instead of spending the start of every meeting counting blog posts we should go through all outages of storage during the week and ask why it happened Matt Doidge: (10:36 AM) We have no site firewall at Lancaster, our storage never has had any problem wahid: (10:36 AM) we made some notes of that discussion - I remember vaguely Ewan Mac Mahon: (10:36 AM) Likewise. wahid: (10:36 AM) There was a lot of detail in that discussion on site setups John Hill: (10:36 AM) Ditto at Cambridge Jens Jensen: (10:38 AM) There are things like ssh you'd want to protect very carefully - Ewan Mac Mahon: (10:39 AM) There often is harm though. We have a lot of email threads caused by firewalls causing wierd problems. wahid: (10:42 AM) to me the iptables firewall config isn't a bit cause of service outages... site firewalls do tend to me more mysterious to the admin Ewan Mac Mahon: (10:43 AM) I have no problem with someone (say) restricing their SSH to access only from particular ranges and using IPtables to do it. That's a reasonable flow from requirement to solution. It is. wahid: (10:43 AM) thats fine confused Ewan Mac Mahon: (10:45 AM) Anyway, boiling this down to a concrete point, I think we can say for sure that it is common practice to run grid storage outside of site firewalls, and fairly common to run them without local ones. Were one to choose to run the storage firewall-less, one would not be unique.