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.
