Attending: Brian, Jens (chair+mins), Sam, Teng, JohnH, Alessandra, Rob, Winnie, Matt, Duncan

0. OBP: None of either, and we have 0 blog posts for this quarter...

1. EOS.  Sam points out we should distinguish the two uses, so let's start with:

   1.1. "Data lake" (CERN flavour)

      Although RAL is participating in Data Lake, it's only done by providing access to someone from
      CERN who administrates the service (using, Brian believes, a non-privileged account).  The
      service is run in the cloud, with a data volume in Sirius mounted.

      If other GridPPers were interested in the CERN-flavoured data lake, could they either get
      involved via the RAL instance (which doesn't sound like a huge amount of invovlement) or
      set up their own data node in CERN's data lake?

      As a philosophical aside, "remote access" is also done through installation and management scripts,
      or even through the scripts that are part of DEBs and RPMs.  It's just that you believe that these
      scripts have been written by individiuals you can trust...

   1.2. EOS Storage (a la Birmingham)

      This is now a task for Edinburgh: before the end of the year (so goes the mission disk),
      perform an evaluation of EOS on top of ZFS and produce some sort of document, either a
      note for internal consumption or if possible, a Wiki page for EOS in the GridPP wiki.

      The relative urgency of this task is prompted by the hoo-hah last week about Birmingham
      becoming an EOS-only site.

      Sam, OTOH, will focus on a CEPH evaluation, to assess suitability for a T2(D).

   2. Update on docs

      Several documents getting out of date, not just storage ones.  Software is updating and
      getting new features, and the documentation describes the old stuff.

   3. Update on DOME.  Works, but has trouble with test scripts that rely on renaming files.
      This, of course, is a fairly exotic case for our usual workflows so is not a huge concern.

      However, write access can happen only with the quota token in the path.  ATLAS have no
      trouble using the service, but tests will fail for the tester forgetting the QT.  There
      is a tool to generate QTs from space tokens.

   4. Update on caching.  Teng has been working with RHUL; analysis gets better performance
      with 100TB disk cache.  However, as last week's discussion of Bham use of remote access
      to Manchester shows, there may be impact on networking.

      There is a DOMA WG on this topic, seeking to understand caching patterns.  However, there
      are many different workflows, and Teng will check with Stephen, the chair of the WG.

   5. AOB

      NOB