Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @


From EGIWiki
Revision as of 15:05, 19 April 2013 by Fmichel (talk | contribs) (Created page with "== General Project Information == *Leader: Franck Michel, CNRS *Mailing List: *Meetings: <link to Indico container> *Status: In progress *Start Date: 15/04/2013 *Duration: 12...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

General Project Information

  • Leader: Franck Michel, CNRS
  • Mailing List:
  • Meetings: <link to Indico container>
  • Status: In progress
  • Start Date: 15/04/2013
  • Duration: 12 months
  • Customer: Virtual Organizations

Project description


This project intends to help small to medium-size grid user communities perform daily administrative and operational tasks, by developing VAPOR, the Vo Administration and operations PORtal, a generic tool to assist community managers and support teams in performing their daily activities. Such communities may typically have no or few dedicated IT support, have scattered scientific activities or fragmented user groups, and may possibly (although not necessarily) make an opportunistic usage of the resources.

This portal is expected to

  • help such communities sustain their model by mutualising the administrative and operational cost at the level of a Virtual Research Community (VRC) or beyond,
  • facilitates the outreach of new user communities by making it easier to start with the administration and operations of a VO. This portal will be available to any community wishing to deploy it, and licensed as open source software.

The primary use case of this project will be the Life-Science Grid Community (LSGC), starting with the biomed Virtual Organization (VO), and mutualising this activity with other VOs of the LSGC.


Operating large subsets of the European Grid Infrastructure (EGI) with reasonable quality of service requires substantial effort to cope with runtime issues like hardware failures or configuration flaws. While this cost is acceptable for large and structured communities such as High Energy Physics backed with a solid IT support, it is often out of reach for small VOs and fragmented communities. The Virtual Research Community (VRC) model has encouraged such communities to organize and structure themselves, as illustrated by the Life-Science VRC (LSGC) that gathers five VOs related to the Life-Science field.

Among them, the biomed VO has set up a volunteering-based technical support team, which goal is to be the technical liaison between the VO users, the resources providers, and the EGI instances (UCB, OMB, UCST). Most active users of the VO contribute their time and experience to perform this job on a volunteering basis, and relay each other during duty shifts. However, the two-years experience of this team shows that the effort required to operate such a VO remains high even when mutualised with members the VO, and it is most likely unreachable for new emerging communities.

Finally, this experience suggests that, to be sustainable, the volunteering model should be mutualised not only within the VO, but also with other VOs, in order to reduce its cost while improving its efficiency.

Some communities require operation and administration tools tailored to their model

A large variety of existing tools and portals (SAM, VO Admin Dashboard, VO Operations Portal, VOMS) are available to assist VO managers and support teams. While some are very generic, others are designed to meet somewhat specific contexts. An example is the CERN Experiment Dashboard, which, although generic and customizable, is tailored for large VOs with common needs, and does not easily fit in the context of smaller "opportunistic" VOs with heterogeneous user groups.

The insight gained in biomed attests that mutualising the effort at the VRC level still requires efforts. In particular, some administration and operational tasks need to be facilitated or automated in different areas: community users management, community-wide accounting, data management, quality of service (QoS) monitoring. Incidentally, the VRC model having no technical existence in the middleware, VRCs lack tools able to provide "VRC-aware" views. From these observations, in 2011 the LSGC members agreed on the need for a tool primarily tailored to the LSGC VOs, though generic enough to meet needs of other similar communities.


project mandate - who has directed the formation of the project, what has been defined as the project objective. Who is the project leader/manager, who are the stake holders (this is vitally important as you need to be clear on what it is that is expected of you), who are the recipients of the project output and when is this required by. Describe the formation of the project team (how why and where), the allotted resources (time, people, stuff, money etc). There could be a number of sub paras. You should also make clear that the scope of the task is realistic and that you can achieve it – as such, complete this introduction at the start of the project and re-check it periodically as you progress.


This section should be short – it will be limited to stating exactly what the objectives of the project are to be. Ideally it will be aligned which the outcome of the project though frequently the results of a project differ significantly from what was originally intended (and that is not necessarily a bad thing). But a good project will set out with a clear idea of what it is that someone wants the project team to achieve. Note that there may be an ultimate Aim or Goal which is important to know and understand but may not be the aim of this project (eg a study to identify a cause of a disease may be a full project but the ultimate goal is to develop a cure or a prevention). If there is a series of specific deliverables, these can be detailed later.


List and describe the specific tasks with target dates for completion.


  • Deliverable 1 description and target date
  • Deliverable 2 description


  • Member 1 Name and Role in team
  • Member 2 Name and Role in team
  • Stake holder 1 and reason for interest
  • Stake holder 1 and reason for interest

Emerging Information

if relevant - may change the nature and objectives of the project


How is the Project Team to be resourced and how will members work? How much effort will be required from each individual, how will this effort impact contributing organisations? – do not confuse VT participants with stakeholders. VT participants do work for the project – others don’t have to do any work for the project. How will your funds be consumed?

Progress Reporting

How will you measure your progress and how will you report this? To whom? The objective here is to assure others that your project is on track, but if there are problems then this is the path to getting help and more resources (time, funding, effort).

The Project Leader will provide a short emailed progress report on a weekly basis. The report will be due by 17:00 on Fridays and is to contain details of: ● Work achieved that week ● Work planned for next week ● Progress against the goals in the project plan ● Issues that the virtual team leader needs help with (e.g. non-responsive partners, more resources, support from teams, etc.)

The Team project manager will also provide a more comprehensive input for the EGI InSPIRE quarterly reporting.