Attending: David, Jens (chair+mins), RobC, Wenlong, Teng, Vip, Winnie, Matt, Dan, RobA


0. Operational docs upgrade DOMA\{Access DOMA} TWG posts (aka standing 
items)

   No issues reported (in any category).

1. https://indico.cern.ch/event/813744/

 1.1 The authorisation/tokenisation working group.  Seems to already support StoRM and dCache
     (or rather, the other way around).  Authorisation is clear enough - JWT formatted according
     to the WLCG recommendations - what is token-based authentication?  OIDC, presumably?

     In principle, we could find a StoRM (or dCache) site and turn it (token based auz) on,
     if we wanted to contribute/test it.   Could also be relevant for IAM integration, but
     is otherwise not a pressing need.

     It is notable there is another hackathon in May in Lund.  If we do anything, this might
     be a good place to do it for/by/at.

 1.2 EOS - main question being whether EOS is an option for a T2.  Although it's run in
     Birmingham already, that does not necessarily generalise to a general future T2
     - for one thing, Birmingham supports ALICE which is different from the rest of
     GridPP T2s.  Edinburgh has trialled an EOS installation and could report on this;
     Vip had also tested it in Oxford.

     No mention of underlying features of storage?  Except for a distinction between
     tape and disk.

 1.3 DOMA QoS.  Lots of interesting things in Paul's presentation but it also raises questions.
     CDMI support is interesting; dCache has long supported it, but also EOS, and it gives an
     opportunity other than SRM to select QoS.

     But how does it work - is it like HTCondor ClassAds being reinvented?  Like the EOS
     talk the workshop didn't seem to dig into the types of storage below the SE, except
     for BNL's MAS talk which is a bit abstract; like the SAGE project, they were considering
     migrations of data - well, basically HSM.

 1.4 The INFRAEOSC 3 and 7a stuff relates to future operations of services which fall into
     two broad groups, EGI's (presented here) and EUDAT's.  Not so much a concern for operations
     but more a part of the "big picture" of the future of services - further convergence -
     (sort of) in EOSC.

2. DPM roadmap (which, I hope would be of interest also to non-DPM 
   sites, as they might choose to migrate to DPM, or might be interested in 
   DPM sites considering alternatives, specifically those, if any, 
   considering becoming xroot cache only)

   We didn't really have time to discuss the roadmap in depth and Sam wasn't in the call
   but the idea is that it's part of a T2's decisions on future directions of storage.
   We shall return to this topic in general, and the whitepaper in particular.

   However, on the topic of DPM migrations, we discussed Bristol's migration path.  A machine
   is allocated for Sam to test/work with, and Luke is generally of the opinion that it will
   work but we need to progress this not just to support Bristol but also because this, too,
   is of relevance to T2s' roadmap/plans.

   A related note is whether to run xroot which is quite WLCG/HEP specific, or HTTP which is
   very generic.  The former has the advantage that it is less known to the bad guys, so
   is not so much victim of h4xors and sCr1pt k1ddies.  The latter has the advantage of being
   able to use very mature COTS (as it were) components.  But as Winnie points out, HTTP
   servers see a lot of attacks.  Moreover, with requirements on uptime, it may not be so
   easy to bring an endpoint down for upgrades/patching? - but this should not be an excuse,
   of course, for running any system with known vulnerabilities.

   Related to this again is the incident handling and the associated software vulnerability
   assessment - when the incident relates to a particular software component.  When there are
   fewer different kinds of components, it is easier for Linda's SVG to make assessments,
   and this is of course harder with lots of diverse implementations, or very obscure software.

3. Introduction to Teng's monitoring

   Teng was in the call but we ran out of time and will cover it some other time.

4. DOMA access draft

   Next week - or later.

$. AOB



From Winnie Lacesso to Everyone:  10:13 AM
Does EOS work with HDFS backend?…..
From Daniel Traynor to Everyone:  10:15 AM
Birmingham use EOS,, have done so for >1 year. What’s their experience?
Maybe a talk from Birmingham on EOS for the GridPP collaboration meeting?
From rob-currie to Everyone:  10:38 AM
Ah, I remember RDF...