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:
- This is the biweekly DTEAM meeting
- The intention is to run the meeting in EVO: http://evo.caltech.edu/evoGate/. Join the meeting in the GridPP Community area.
- The phone bridge number is +44 (0)161 306 6802 (CERN number +41 22 76 71400). The phone bridge ID is 64688 with code: 4880.
Review of weekly issues by experiment/VO
-- Check on transfer problems http://hepwww.rl.ac.uk/nraja/UKUploadProblems/index.html
"Two small issues.
The LHCb upload problems continue at Glasgow and Brunel. I am not so sure about Sheffield, and will be happy to wait and see.
The upgrade of the LHCb castor instance at RAL to 2.1.9 went off reasonably well, with the exception of a few minor ongoing problems which are being worked on right now".
- Only Brunel now seeing problems?
From PMB update "one minor thing is that some T2s are being asked to increase the amount of centrally managed space to 150TB (from 100TB). I have said yes to Imperial and no for Brunel so far (because of their reliability issues).
One positive comment - we noticed that Imperial has analysed more CMS events than any other T2 over the last month and is 3rd or 4th since data taking started this year. There was a big increase in throughput after we added a Netapps box for the experiment software areas and user directories."
- Experiment blacklisted sites
- Experiment known events affecting job slot requirements
- Site performance issues
-- Was there any feedback on the revised WLCG Tier-2 August availability figures. http://gvdev.cern.ch/GRIDVIEW/downloads/Reports/201008/wlcg/lcg_tier2_aug2010.pdf.
Meetings & updates20m
ROD team status (any points to raise to sites or issues to follow up?)
- Tier-1 update
- The next WLCG Grid Deployment Board will be on 13th October (the agenda will appear here soon http://indico.cern.ch/conferenceDisplay.py?confId=72063). Graeme has the honor of being T2 rep this month.
- Escalated tickets https://gus.fzk.de/download/escalationreports/roc/html/20101004_EscalationReport_ROCs.html
3 tickets on hold.
56316 - NGS-RAL not in BDII
58733 - RAL-PP biomed. dcache issue.
61228 - ALICE RAL T1.
CREAM status & top-level BDII failure15m
- Which sites have it
- What are the reasons for other sites not having it?
- What currently happens when the RAL top-level BDII is lost
- What usage do the other BDIIs get
- The proposal: http://indico.cern.ch/getFile.py/access?contribId=4&sessionId=0&resId=0&materialId=0&confId=82009
- GOCDB3 to 4 interface change next week (https://goc.gridops.org/downtime/list?id=93355468).