In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
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
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.
Status of site upgrades5m
Status of client tools5m
Confirmation of where Sites should obtain installation kits5m