CCRC'08 Storage Solutions Working Group Con-call

28/R-015 (CERN)



Show room on map
Mailing list:

To join the call, do one of the following:

  1. Dial +41227676000 (Main) and enter access code 0139097, or
  2. To have the system call you, click here.

(Leader code is 0129124).

    • 1
      Minutes of the last meeting / call
      Brief notes from CCRC08 Storage Solutions Working Group of 25 Feb 2008 Agenda with attached material at : 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.
    • 2
      Preparation for WLCG Collaboration Workshop (21 - 25 April at CERN)
      Urgent issues to discuss: 1. Behaviour of srmPrepareToPut when overwrite flag is specified and a second srmPrepareToPut request is issued. The proposal is to abort the first request (ongoing transfers continue) invalidating the corrispondent TURL and honor the second request. This will solve the "File exist" problem experienced now through the FTS. 2. Performance of bulk deletion through SRM 3. Staging requests not completing or honored in default pool 4. Changing spaces for files T1D1 -> T1D0 difficult for dCache sites ? Request coming from CMS. Is this an issue we need to reconsider ?
    • 3