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:
The meeting purpose is to:
- Evaluate successful methods of Middleware Readiness practices by selected middleware products.
- Discuss how to better involve the experiments in this effort.
- Find ways to reward the WLCG sites willing to participate in the testing of new middleware versions.
Repository: Every Product Team (PT) uses the repository of their preference (EPEL, Maven, etc). Products should stay for sometime in a 'testing' partition before making it to the 'prod' one. If, after April 2014, the EMI repository is no longer maintained, an alternative should be discussed and a transition plan should be decided.
Process: Examine the workflow used by DPM, dCache, StoRM and, if they can serve as examples, document their reasons of success.
Communication: Communicate conclusions from this experience to the WLCG Ops Coord meeting.
Experiments: Maximise experiment involvement in testing new versions of these products of choice. Talking to our peers, in SDC/OL, linked to the experiments, is the first step to this direction. One representative per experiment is needed, as a member, in this WG.
Sites: Assist PTs to find sites willing to test new versions of their products. After establishing the first links, via a few dedicated meetings within the WG, we should smoothly agree on a 'formal' procedure. We should discuss, first within the WG, then with the experiments and the sites, how site involvement can be recognised and rewarded. Would sites be willing to:
have a testing infrastructure AND would the experiments agree to adjust their workflow to use it?
agree to upgrade their production infrastructure early? If yes, WLCG should be more tolerant to site unavailability, in case of problem, acknowledging the site's willingness to take the risk.
EGI: Keep the dialog open with EGI, maybe bridge the processes used in the two communities, i.e. by making available the testing versions for sites which are both WLCG and participate in the EGI Staged Rollout. With experiments' agreement to participated in such tests, we can help to make the UMD production versions available sooner.