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:
Science Park 140
1098 XG Amsterdam
The 19th TCB meeting will be held in meeting room N328 at NIKHEF.
This is a F2F meeting, please see the EGI.eu directions for more information, or NIKHEF directions directly. However, we have prepared an audio conference bridge, please see the attached dial-in information for details.
Note: The meeting room N328 is not reachable from the main entrance staircase. From the main entrance, pass the reception and turn right immediately after it and follow the hallway turning left, passing a large open plan storage area. Arriving at the next staircase near to meeting room N041 (see floor plan for details) take the elevator (or use the stairs) to get to the 3rd floor and N328.
NIKHEF floor plan
Alberto Di Meglio
Doina Cristina Aiftimiei
EGI ecosystem support model
Held in a workshop style, this session will begin with setting the context for Technology Providers in the larger picture.
Through discussions and active participation and contribution this session seeks to elicit specific and concrete support models for different types of Technology Providers: Ranging from small teams taking ownership of a set of specific libraries to Platform Integrators that assemble and bundle services, libraries and other types of software into self-sufficient and well defined Community Platforms, all contributions are part of the EGI ecosystem.
The goal of this session is to find commonalities and differences between support models, as well as backing Technology Providers that are interested in taking discussions further into commitment agreements for these models.
After having identified, in the previous session, a number of support models and Technology Providers that fit that scheme and are interested in discussing committing to it, this 2 hour session will examine and validate the EGI Platform architecture.
Participants will look at the current EGI Platform Architecture, what subsystems and services each modeled platform will or should comprise of, and where the interaction and integration points between different platforms will be.
In this workshop, participants will also work towards drafting a number of Community Platforms, identify product teams that wish to contribute software to them, and who shall be responsible for assembly, integration and provisioning.
Overview, organisation of the whole picture, and alignment with the EGI strategy
An overview and scope of the EGI principal platforms:
The EGI Core Infrastructure Platform - A solution to federate distributed e-Infrastructures.
The EGI Cloud Infrastructure Platform - A federated IaaS Cloud platform
The EGI Collaboration Platform - Services to facilitate collaboration across Research Communities
Community Platforms, UMD and the Software Repository30m
What is EGI's definition of a Community Platform? Does it fit the current landscape, does it sufficiently capture reality? What needs to be changed in that definition, and for which reasons?
Which Grid stacks would fit this definition and might emerge as marketable Community Platforms in the ecosystem? Which research communities do these Community Platforms support?
What will happen with the UMD? What will it provide? What is the scope of the UMD, and does it have the potential to cannibalise on Community Platforms?
Which role does the EGI Software Repository play in this ecosystem? Which services can it offer to Technology Providers, and are Product Teams required to use it, and under which conditions?
Back to back with the discussions around community platforms, this contribution aims to focus on aligning Community Platforms and the EGI Platforms with each other.
Another topic of discussion here is a potential new platform to discuss: An "EGI Commodity Computing Platform", a simple (or simplified) set of components bundled together to lower the barrier for research communities to engage with EGI. Which components and services would fit such a platform? Who owns it? Who maintains it? which type of researchers does it target?