Brief notes from CCRC08 Storage Solutions Working Group of 25 Feb 2008

Agenda with attached material at :
      http://indico.cern.ch/conferenceDisplay.py?confId=29191

Present: J.Shiers (chair), H.Renshall (notes), B.Koblitz, J-P.Baud,
         M.Branco, A.Pace, S.Campana, T.Cass
Phone: P.Fuhrmann, G.Oleynik, T.Perelmutov, B.Bockelman, P.Charpentier,
       S. De Witt, J.Gordon, F.Donno

Discussion of SRM v2.2 key methods and behaviour:

J.Shiers said that so far ATLAS, LHCb and CMS have uploaded (to the agenda)
their prioritisations of the list of SRM v2.2 issues though the CMS one
is not yet the official position of the experiment. These three are in
agreement on the top two issues though not in the same order namely:

protecting spaces from misuse combined with implementations being fully
voms aware

handling space tokens for 'more than write' (i.e. PrepareToGet/
BringOnline/srmCopy).

JS asked what was currently lacking in voms awareness. BK replied that
writing into CASTOR at CERN does not take the voms group into account.
SdW added that CASTOR still uses the gridmap file. JG asked if dcache
was fully voms aware and JS thought this was a long way off. JS suggested
we should be looking to test the two top priority extensions to SRM 2
during the next annual readiness test before the years LHC data taking -
i.e. CCRC'09. GO said that, in considering priorities, they have not yet
implemented 'change space for files' and was this still needed ? PC said
that we cannot have protection from misuse without voms awareness. JG
gave his definition of the meaning of voms awareness as being access
control based on voms groups and roles.

PF said that they (for dcache) are sufficiently voms aware to support
ACLs on space tokens. SdW said the same for CASTOR proposing to add an
srm attribute to the space tables but adding that gridftp continues to
use the gridmap file. PC said we are asking for protection in the SRM
interfaces which sounds to be fairly easy in CASTOR. SdW promised he would
quantify the effort and give a rough timescale. For dcache PF said a bit
of code was missing and estimated a month or two but that this would
conflict with work on handling space tokens for 'more than write'.

JS asked (again) if both priorities could be done in all mass storage
systems by this time next year, reminding that for the May run of CCRC'08
we are really only considering workarounds rather than permanent
solutions. PC asked if in that case can we expect all the current
'annoyances' in Flavia's SRM 2 problems lists to be fixed for the May
run. FD said that two of them, selecting tape sets and the dcache 'file
exists' problem are done. PC added that he meant issues like the
non-return of space to a token after file deletes recently seen in dcache
at IN2P3. FD said this applied to T1D0 space and PF thought this should
be working both after a file delete (with a minute or two of delay) and
a migration to tape and wondered if IN2P3 was downlevel in dcache. FD
thought they were and in addition promised to come up with a list of
remaining 'annoyances' for the next meeting.

JS summarised that the planning is to fix all known problems by May
leaving the misuse protection/voms awareness and tokens on recall till
later adding that we will need to precise what we mean by voms awareness
and this may lead to another M0U extension. PF preferred to call the
misuse protection 'space token protection' while TP wanted 'voms aware
control of an ACL on a space token'. PF then remarked he understood the
LHCb statement on misuse protection but not that of ATLAS (both are
attached to the agenda). MB reminded that he had sent around by email
a clarification from ATLAS last week which HR pointed out he had attached
at the end of last meetings minutes attached to this agenda. SdW reminded
that changing storage class implies space token changes and asked if the
need for ACLs is only on writing. PC said it was but that this included
the operation of bringOnline into a T0D1 space.

JS finally summarised that access control and bringOnline space tokens
were the remaining priority issues. He proposed that the next CCRC'08
face to face meeting on the 4 March would go through all CCRC'08 issues
and look ahead to these two remaining priority issues with further
follow up and planning to be made at the April face to face meeting
and later WLCG collaboration workshop.