Attending: JohnH, Sam, Teng, Winnie, Jens (chair+mins), Ste

One day we will have an agenda entirely in TLAs! but we are some way away
from having minutes entirely in TLAs.

0. OBP

   NOI (No Operational Issues)

   NBE (No Blogposts Either)

1. Data lakes discussion (postponed from last week)

   So Brian is not here, and is, in fact, away, and we don't seem to have any more access to the
   CDL (CERN Data Lake) but in principle...

   So we have:
	- The CDL
	- Any other data lake we might build - whether out of EOS or something else;
	- CDL (Commercial Data Lakes).  The latter, judging from last year's experiments with the
	  Azure one, presuppose a specific simplistic data format like CSV or TSV, but then
	  provide processing facilities.

   There is some similarity to the on-list QoS discussion in the sense that data lakes are like the (original)
   grids where you shouldn't care where your data is, and data can move from cold to hot storage.  Indeed,
   in the grid version, SRM provided methods for bringOnline and custodial etc. (durability) and latency,
   albeit somewhat simple versions of it (and it was probably a good idea it wasn't any more complicated...)
   The DOMA discussion document essentially, in Sam's summary, centres around latency-based lakes or regional
   lakes.  In the UK, we obviously have a region; and could potentially experiment with cross-site distributed
   storage as a GridPP or dteam VO; if we need cross-site latency, it might just be perfSonar numbers plus
   constant?  It would also, cf Sam's comment on the list, be interesting to look again at the different codes
   available and their relative merits in our situation...

   Also, in theory, a data lake should solve Simon's problem of site maintainability because the MDL (Magic of Data
   Lakes) where you can just close your eyes and clap your heels together three times (no pentagrams involved) will
   make it all good.

   The SAGE project - or _a_ SAGE project, as lots of projects were called SAGE - did some work with storage vendors
   on HSM (Hierarchical Storage Management) [link in chat] so we could maybe learn from the stuff that was made
   public.

   Sam opines that the opportunity for doing QoS [as proposed] was four years ago.  Maybe we can still do something
   now so we will be less unready the next time an opportunity comes around - or at least we will have a response.

2. QoS, TWG, Tape

   The QoS was discussed above; but mostly the messages on the list summarised the position.

3. AOB

   NOB

[link to DOMA Data Lakes doc]
SAGE project on hierarchical storage: http://sagestorage.eu/
Not easy to find because there's more than a few projects called SAGE
Today at 10:24