phone conference

28-R-006 (CERN)



Use these links to join the conference toll-free:


Or dial +41227676000 and enter access code 0160191 (leader code: 0150218)

Mailing list:

Web archive: here

    • 15:30 15:35
      Minutes of last meeting 5m
      Present: J.Shiers (chair), H.Renshall (notes), F.Donno, J-P.Baud Phone: J.Gordon, P.Fuhrmann, T.Cass, A.Pace, G.Oleynik Status of Site Upgrades: For CASTOR JDS reported CERN was uptodate, JG belived RAL was in production and FD reported CNAF have upgraded. For DCACHE PF had not made a recent survey but knew only FZK had enabled the space manager so was publishing space tokens. FD added that they were not yet working as FZK was waiting on a more detailed definition than just the space token names. TC added that ATLAS have now published a long list of space token information beyond that reqiuired for the experiment tests. JDS thought it satisfactory that all sites, except he thought PIC and TRIUMF, were SRM 2 ready in either CASTOR or DCACHE. He asked the status of the client tools and J-PB said that gfal and lcg-utils will go to the PPS this week. Status of Experiment Testing: FD reported that CMS find that lcg-cp works better than srm-cp and have filed some bug reports. They will now try to use FTS and are discussing which space tokens they would like. PF queried why they prefer lcg-cp and FD said it does not use srm-cp, which has two versions, and has no compatibility problems. GO thought it would also be more performant as there is no indirection and asked what was being done about the compatibility issues. FD is reporting them to the SRM testers list and JDS said that after the February CCRC08 we must make a prioritised list of the outstanding problems. SRM 2 and Space Tokens - GDB Proposal (documents attached to agenda): JDS introduced this by saying the proposed stop-gap solution to be put to tomorrows GDB meeting does not imply any development but does have deployment implications. He asked if the technical experts saw any problems with the proposed approach. PF said he supported the draft and that he thought all Tier 1 knew how to configure their dcache using a different space per path. TC however said he thought the December MB agreed that lcg tools would not use a space token and that they had now done a CASTOR development that was useless. Parts of the proposed solution will not work when a space token is given e.g. a user may attempt to recall a file to a pool where he has no access. TC thought recall interfaces should not use any space token but rather use the other parameters. FD said experiments want to pass a token in order to help CASTOR make a decision. TC repeated we should stick with the FNAL/December agreement and asked what other information could be given to CASTOR to which FD replied that the only other info for castor is the userid while for dcache it would be the path. TC thought that RAL, CNAF and CERN should agree, for CASTOR, whatever is easiest for the sites and that they would be meeting next Wednesday. JDS pointed out that the proposal is intended as a stop-gap solution and that we would gain experience during the February ccrc08. PF asked if TCs worry was that giving a token to CASTOR may produce a wrong result ? TC replied he wanted all CASTOR sites to behave the same way and he was worried data may end up being copied between disk pools, something experiments have criticised in the past. He agreed that giving tokens in the Feb tests should work but may generate unecessary copies. He would mail the CASTOR sites to try and get a concensus in time for the Wednesday gdb. The next conf call was then scheduled for 15.30 on 21 Jan.
    • 15:35 15:40
      Status of site upgrades 5m
    • 15:40 15:45
      Status of client tools 5m
    • 15:45 15:50
      Confirmation of where Sites should obtain installation kits 5m
    • 15:50 15:55
      Date & Time of next calls 5m