Forms of VO registration documents

1.1       Accepting a VO

Before a VO can be accepted the VO supervisor must:

 

  1. Verify that there is no existing VO with significantly overlapping goals. This can be done through the VO list of the Operations portal [R5]. 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. Choose the scope of the VO.

 

1.1.1      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 1 in the table above):

 

  • Section General information
    • Mandatory field Name

    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.

     

    • Mandatory field Description

    In principle any text 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 grid, 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.

     

    • Mandatory field Discipline

    It is simply verified whether there is a contradiction between the field Description just discussed and this one.

     

    • Mandatory field Supported Middleware

    There are four options to choose which middleware the VO support, portal automatically checks that at least one option was chosen by Vo Manager.

     

    • Mandatory field Acceptable Use Policy (AUP)

    The acceptable use policy which is meant here is the VO AUP.

    On the “New VO registration web page” [R 6] 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.

     

    • Mandatory field VO homepage

    This field must be verified whether the home page contains information about the ongoing/planned grid 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.)

     

    • Mandatory field Enrolment URL

    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.).

     

     

  • ·Section VOMS Information
    • Mandatory field “VOMS Configuration”

There are two options the VO Manager must choose: one is a VOMS server which is pulled from GOCDB and another is a request for support in setting up the VOMS server.

 

  • ·Section VO SU at GGUS
    • Optional field “check box”

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.

 

  • ·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, User Support, 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.

 

  • ·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 NOC/ROC managers list in case of Regional VOs and also to determine responsibilities for support in case of additional resource requests made by the new VO.

    If the VO is a Regional one, this field should be updated before the Status field.

    Updating this field triggers notifications to the  VO Services group list  and to the NOC/ROC 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 to the  VO Service group list  in all cases and to the NOC/ROC managers list in all cases except for Regional VOs where only the corresponding NOC/ROC is informed.