PROC14 VO Registration

From EGIWiki
Jump to: navigation, search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

Documentation menu: Home Manuals Procedures Training Other Contact For: VO managers Administrators

Alert.png This article is Deprecated and has been moved to

Title VO Registration
Document link
Last modified 22 November 2019
Policy Group Acronym OMB
Policy Group Name Operations Management Board
Contact Group
Document Status Approved
Approved Date 2019-09-19
Procedure Statement The document describes the process of enabling a Virtual Organisation (VO) on the European Grid Infrastructure (EGI) and the parties who are involved in process execution.
Owner Vincenzo Spinoso


The document describes the process of enabling a Virtual Organisation (VO) on the EGI Infrastructure and the parties who are involved in process execution.

Users of EGI are organised into Virtual Organisations (VO). A VO is a group of people that have similar focus in their work and have a common wish to share access to a subset of EGI resources. Membership of a VO (or a group within that VO) is how access is granted to those resources.  A typical VO provides some base-level access to the resources for all VO members, with some members having elevated privileges.

The focus of this document is on the tasks that VO representatives and the EGI staff have to accomplish in order to register and validate a new VO on EGI. The purpose of this page is to capture the VO registration workflow so it can be learned by VO representatives, by EGI staff as well as it can be improved in order to meet new requirements.

For other aspects of VO management (e.g. operation support, resource/service allocation, decommissioning) please consult with the VO Manager Documentation Wiki page or contact EGI User support group <>.


Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

  • VOMS - The Virtual Organization Membership Service (VOMS) is an attribute authority which serves as central repository for VO user authorization information, providing support for sorting users into group hierarchies, keeping track of their roles and other attributes in order to issue trusted attribute certificates and SAML assertions used in the Grid environment for authorization purposes.
  • GGUS- It is the primary means by which users request support when they are using the EGI Infrastructure. The GGUS system is the main support access point for the EGI project. The GGUS system creates a trouble ticket to record the request and tracks the ticket from creation through to solve.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Entities involved in the procedure

  • VO manager (VM): person responsible for initiating the registration process.
  • VO supervisor (VS): person delegated from the EGI Operation team to handle the process on behalf of EGI project and responsible for the approval of VO registration requests.

VO registration


Any person who can authenticate to the Operations Portal (e.g., via an EGI Check-in account) can register a new EGI VO.

The person initiating the registration is called the VO manager. After the VO is setup and operational, the VO manager is the person who is primarily responsible for the operation of the VO and for providing sufficient information about VO activities for EGI and for VO members (to both people and sites).

VO lifecycle - VO states

A VO is in one of the following states:

  1. NEW: this is the initial state when the VO creation is requested. It is automatically assigned.
  2. PRODUCTION: the target state of a VO. It is manually given to a VO by the VO supervisor as a result of this procedure.
  3. SUSPENDED: this state is entered when the VO no longer has valid information in VO id card. This state may be temporary or the preparation of VO deregistration. Manual intervention is needed to put a VO into this state.
  4. DELETED: state for VO that have been terminated.

Note that manual state changes can only be made by people registered in VO Supervisor role on the Operations portal or by the Operations portal team itself. This document covers the VO lifecycle from “non existing” through NEW to PRODUCTION.


The following table describes the VO registration process, listing each of the steps that need to be performed, the people who are responsible for the action, and the physical action that need to be executed to complete the step.

  • Actions tagged VM are the responsibility of the VO Manager.
  • Actions tagged VS are the responsibility of the VO Supervisor.
  • Actions tagged OP are automatically triggered by Operations Portal
Responsible Action Prerequisites, if any
0 VM

Submit VO registration request

Fill in Web form (the VO Id card) in Operations Portal

How to fill in VO id card

VM must be able to authenticate with the Operations Portal (via EGI Check-in)

Inform VS about new VO registration request

Send notification email to VS, a GGUS ticket against Operations Support Unit is generated to track the request.

2 VS

Check the correctness of VO registration request
Check if the content of the VO ID card in Operational Portal is correct according to the acceptance rules

Must be able to authenticate with the 

Operations Portal (via EGI Check-in)

3 1 VS

OP Inform VS about new VO requiring VOMS server

VS may open GGUS ticket requesting a VOMS server to the new VO, and asking to be assigned to the EGI Catch-all Services support unit.

(Step 0) The VO manager has no agreement with any EGI Resource Center to provide VOMS server for the VO and asked to setup VOMS server for the VO.

2 VS

OP Inform VS about VO requiring new Support Unit in GGUS

VS may open a ticket against the GGUS support unit in GGUS.

(Step 0) VO manager asked to setup a new GGUS Support Unit.
3 VS Verify with VM if the new VO should be manage as a COManage group in EGI Check-in

Open GGUS ticket to Check-in (AAI) support unit requesting the creation of a group in COmanage, with VM in copy. Specify in the ticket who should get the administrator role of the new group. Report this ticket in the general one created at step 1.1.

The VO will use services that don't require authentication with X509 certificates (e.g. cloud services)
4 VS Ask for update of VO Id card

Send an update request to VO manager using the GGUS ticket.

Data is missing or incorrect in VO Id card.
5 1 VM

Define VOMS server on VO Id card in Operational Portal

If not requested in step 1.2, can be done during step 0. Otherwise VM needs to wait for setup by EGI Catch-all Services team.

VO is expected to be managed via VOMS
2 VM Fill in the COmanage enrolment URL in VO Id card in Operational Portal VO is expected to be be managed via Check-in and the VO has been enabled in Check-in.
6 OP

Inform VS that Id card contains VOMS server

VO is expected to be managed via VOMS
7 VS Creates a ticket to "Perun" Support Unit in GGUS to ask for support for the VO. If VO is going to use cloud resources and needs X509 certificates

In the ticket, provide the following information:

  • name of VO (English alphabet) + short name of VO (usually 2-10 characters)
  • who should be the VO managers
  • whether the VO is going to be used for EGI Check-in only, or for some other end services as well
  • either the desired user life cycle, or at least which events should trigger a notification for VO managers (new registration to VO, registration changes state etc.)
  • whether VO registrations should be approved manually (by VO managers) or automatically
  • what fields should be in the VO registration form and which of them should be required (the bare minimum is required name + required email)
8 VS

Approve new VO Id card

Mark VO as active from the incoming VO(s) list. The VO status is moved to PRODUCTION in Operational Portal.

9 OP

Inform VS about new PRODUCTION VO

Send notification email to

  • VS
  • VM
  • EGI Community

Accepting a VO

VO supervisor responsibility is to: 

  1. Verify that there is no existing VO with significantly overlapping goals. This can be done through the VO list of the Operations portal. VOs with similar goals (e.g. image analysis) should be advised to join.
  2. Check that the VO Id card contains correct and complete data.
  3. Check the proper scope of the VO.

Valid VO id cards

The following compulsory and optional fields must be filled out by the VO manager as part of the registration process (Step 0 in the table above):

  1. Section General information
    • Name (Mandatory) - The Operations portal enforces a DNS style name. It still has to be verified whether the VO manager whose name and mail address is available in the Contact list update section is authorised to use it. The VO registration procedure requests this but currently no enforcement is done. It is checked, though, whether the VO name is already in use, and if so, portal pops up the notification asking to choose another name. The obtained information is given back to the VO manager if it is not obvious that the owner of the domain and the VO manager are the same person. Note that it is not considered sufficient that the VO manager’s mail address is in the same domain as the VO name’s one, nor that the VOMS server or VO home page address are of that domain, if this information is available. Doubts on domain ownership are not stopping VO registration, as the responsibility of acquiring the domain name is with the VO manager anyway.
    • Description (Mandatory) - In principle any text in English is valid. However, it should describe a scientific or technical activity, or should be related to education. The text is also used to delimit proper resource usage on the infrastructure, so it should be significant for this purpose, i. e. saying “VO giving access to the grid” is a poor description whereas “VO giving access to the grid for training purposes” is completely satisfying. In practice up to now every VO request came with a readable text but some VOs got stuck in the very first stage of the registration (state NEW) because of a too minimalistic view of what is a description.
    • Discipline (Mandatory) - It is simply verified whether there is a contradiction between the field Description just discussed and this one.
    • Supported Middleware (Mandatory) - There are options to choose which grid middleware or cloud resources the VO support, portal automatically checks that at least one option was chosen by VO manager.
    • Acceptable Use Policy (AUP) (Mandatory) - The acceptable use policy which is meant here is the VO AUP. On the “New VO registration web page” the registering VO manager has the choice between a text automatically generated from the Description but where at least some words have to be updated, or a file in text or pdf format uploaded by the manager containing a VO written AUP. In the former case it has just to be checked whether the update has been done; the words to be replaced are “owner body”, included in brackets - “[]” - , and the replacing text must specify the authority enforcing the VO AUP. This is however omitted in one out of two cases but then normally corrected rapidly by the VO manager. If not the VO gets stuck in the NEW state; there are still some of them. If the AUP is uploaded, the complete text has to be verified if it corresponds to a VO AUP. In case of a doubt, in addition to contacting the VO manager a member of the JSPG is asked for advice.
    • VO homepage (Mandatory) -This field must be verified whether the home page contains information about the on-going/planned activity and that this information corresponds to the VO’s Description. Sometimes the scope of the VO can also be determined with this or with the VO manager’s affiliation. (For example about the scientific goals of the community and how the EGI VO helps the community to achieve these goals.)
    • Enrolment URL (Mandatory) - This field must be verified whether it is functional or simply an optional service to the VO. Additionally, the information available on the enrolment web page might give some indications on the purpose and scope of the VO as well as on the attitude concerning security (availability of a Grid AUP, reminder of correct resource usage etc.).
    • Support procedure url (Optional): The support procedure url where it is described how support is provided for this VO and how users should communicate in order to report an issue or request assistance
  2. Section VOMS Information
    • “VOMS Configuration” (Mandatory) - There are two options the VO Manager must choose: one is a VOMS server which is pulled from EGI Central services database and another is a request for support in setting up the VOMS server.
  3. Section VO SU at GGUS
    • “check box” (Optional) - There are two options the VO Manager can choose: one is a default – No. If VO Manager will check a box, the new ticket will created for GGUS support unit and VO Supervisor will keep track of the process.
  4. Section Generic Contacts - There is only one not mandatory contact in the list of this section shown on the VO ID card,Operations contact. Other fields (VO Managers, Security, VO Users) are mandatory and currently, new registration requests must contain a valid address in these fields. Validity should be checked by sending an e-mail to it, requesting confirmation of receipt.
  5. Section Change status & scope
    • Pull down list Scope - As already indicated in the discussion of the previous fields, any hints are used to determine the value to be selected for Scope. In case of a doubt - which is the normal case here - a suggestion is made to the VO manager. The field is then updated only after a feedback from that person. Assigning a correct value is important for limiting the noise especially on the National Infrastructure managers list in case of National VOs and also to determine responsibilities for support in case of additional resource requests made by the new VO. If the VO is a National one, this field should be updated before the Status field. Updating this field triggers notifications to the VO Services group list  and to the National Infrastructure managers list in all cases.
    • Pull down list Status - If all previously mentioned fields contain valid values, either since the beginning or after some communication with the VO manager, the status can be changed from NEW to PRODUCTION. The VO will be then active and in production state. Notifications are sent to the  VO Service group list  in all cases and to the National Infrastructure managers list in all cases except for Regional VOs where only the corresponding  National Infrastructure is informed.

Scope of the VO

As part of the VO approval step (Step 5 in the table above) the scope of the VO must be defined by the VO supervisor based on information provided by the VO manager either in the VO Id card, or through additional channels (e.g. in email). The scope must be one of the following:

  1. GLOBAL: the VO is supported by sites from multiple countries and all of these countries are represented by its National Grid Infrastructure (NGI); comprises an international user community and/or has international resources coming from sites of different countries represented by their National Grid Infrastructures (NGIs).
  2. NATIONAL; i.e. sites and users are located within the same country. Users might come from elsewhere but they are working inside the scope of the same National infrastructure where the sites are. The associated National infrastructure is part of the scope, like for example “NGI - Italy” or “NGI - France”.

In case of invalid, unclear or ambiguous entries in any of the controlled fields of the VO Id card, or in case of doubts about the goals of the VO, the requestor must be contacted and invited to clarify the situation or to correct the entries.

Revision History

Version Authors Date Comments
4.1 Malgorzata Krakowian 7.11.2012
  • Removal of point 6.2 which stands: Inform EGI that New VO SU was created in GGUS; Send notification email to VO supervisor and NOC/ROC managers list
  • point 6.1 was renamed to point 6 and removed: Send notification email to NOC/ROC managers list

M. Krakowian 19 August 2014 Change contact group -> Operations support
M. Krakowian, Paul Millar 25 August 2014 Making procedure more readable.
Alessandro Paolini 2016-06-08 Changed contact group -> Operations
Alessandro Paolini 2016-11-18 Changed the link to the VO registration page
Alessandro Paolini 2019-08-09 added the steps for creating the VO in Check-in. Gathering comments by NGI Managers.
Alessandro Paolini 2019-11-22 Moved to step 2 the validation of the information by VS; added description of the optional field "Support procedure url"
Alessandro Paolini 2021-06-15 step 7: added some information to provide in the ticket to PERUN