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 @ egi.eu.

PROC13 VO Deregistration

From EGIWiki
Jump to navigation Jump to search
Main EGI.eu 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



Title VO Deregistration Procedure
Document link [1]
Version - last modified 0.1
Policy Group Acronym OMB
Policy Group Name Operations Management Board
Contact Person operations@mailman.egi.eu
Document Status DRAFT
Approved Date N/A
Procedure Statement A procedure for the steps involved to decommission a Virtual Organization currently registered in the EGI infrastructure.

VO Deregistration Procedure

A VO registers [R3] to the European Grid Infrastructure in the perspective to get access to resources supplied by the participating sites. The VO is bound by the appropriate operational and security policies [R4, R5, R6, R7] but those documents do not define how to handle situations like a VO wanting to leave the European Grid Infrastructure. This document proposes a procedure to permanently deregister a VO from the European Grid Infrastructure.

The current document is intended to the VO manager, who understands the needs of the VO users and is responsible to apply the registration and deregistration procedures, and to the VO supervisor, who coordinates the overall process and takes the VO manager role case he is unavailable, unresponsive or unable to commit to the defined procedure timelines. It is certainly also beneficial for site managers, as well as people involved in grid management aspects, especially in the fields of security and operations.

Note: a separate document will provide the guidelines to propose and agree a VO deregistration. This document contains the steps to be performed once the decision to decommission the VO is taken.

Definitions

  • Resource Centre refers to the definition in the "Resource Centre OLA".
In this document, the term "site" is deprecated, and Resource Centre has been used in its place.
  • Other entities involved in this procedure are defined in the EGI Glossary.

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

The main players participating in the VO deregistration procedure are:

  • The VO manager.
  • The VO supervisor.
  • The VO deregistration coordinator.
  • The sites supporting the VO resources.
  • The VO users.

The tools available to support the deregistration procedure are:

  • The EGI Help-desk (GGUS) [R8].
  • The Accounting Portal [R9].
  • GSTAT [R10].
  • The EGI Operations Portal [R1].


Contact information

  • EGI Operations: operations (at) mailman.egi.eu
  • EGI Resource Infrastructure Providers are listed on the EGI web site
  • A list of EGI Operations Centres with their respective contact information is available from the GOCDB
  • EGI CSIRT: egi-csirt-team (at) mailman.egi.eu
  • The list of VO's served by a specific Resource Centre and their ID cards can be retrieved from the Operations Portal.
  • The VO managers and their contact information for a specific VO can be retrieved from the Operations Portal.

Actions and responsibilities

VO Supervisor (COO)

VO Manager (if existing)

VO's and VO managers

  1. give the users the relevant information about the decommissioning (deadlines, involved resources, files, how to handle it)
  2. follow-up and support users in their file migration procedures until the deadline
  3. inform Resource Centre about the status of the migration(s)


Operations Centre

Workflow

VO deregistration

Steps

  • Actions tagged VOM are the responsibility of the VO Manager of the VO being decommissioned.
  • Actions tagged VOS are the responsibility of the VO Supervisor (Currently COO).
  • Actions tagged OC are the responsibility of the Operations Centre
  • Actions tagges VOU are the responsibility of the single VO users
# Responsible Action
1 VOM (alternatively VOM)
  1. Open a GGUS ticket to begin the deregistration process. The ticket should contain the following information:
    • The date of the decision of the VO decommissioning (prior to the begin of the procedure)
      • If available the link to the GGUS ticket that contains such decision
    • The proposed timeline for the decommission procedure:
      • Expected date for the VOMS server decommission
      • Expected date for the Helpdesk support unit decommission
2-a VOM

(Optional step)

  1. Provide a snapshot of the resources supporting
    • List of grid services
    • List of files registered in the VO's LFCs
3 RC
  1. Send a broadcast to all the VO users, specifying:
    • A link to the master GGUS ticket opened at point 1
    • The timeline for the deregistration (minimum one month from the broadcast)
    • The VOMS server is being decommissioned in one month (minimum), after the decommission users will not be able to request a proxy to access the grid services
  2. If there are other VOs accessing the VO data (and only if VOM provides this information):
    • Send a broadcast to the VO Managers of the affected VOs containing the same set of information, asking them to directly coordinate with the VOM to retrieve the relevant data
3bis VOU
  1. Users may ask for an extension of the deregistration timeline
    • The request MUST be submitted within 10 days from the broadcast
    • The request SHOULD be supported by technical reasons (e.g. the amount of data stored in the SEs is too big to be moved within the end of the procedure.
4 VOM/VOS
  1. At the end of the one month period (or longer period, if extended at point 3bis) a child ticket of the master ticket should be opened and assigned to the site hosting the VOMS server that supports the VO, in order to request to disable the VO.
5 VOM/VOS
  1. Change the VO status in the Operations Portal to 'suspended'
6
  1. Broadcast to site managers that the VO has been decommissioned, the broadcast should contain:
    • The link to the GGUS master ticket
7 RIP
  1. If the Resource Centre hosts central services like VOMS or LFC for a given VO,VO Manager, Resource Centre Operations Manager and Resource Infrastructure Operations Manager should discuss finding a new Resource Centre for hosting these services, taking into account pre-existing agreement between VO and NGI. For international VOs, this discussion could be held at the EGI level, especially if a solution cannot be easily found within that Resource Infrastructure Provider.


8 OC
  1. Once step 6 is completed and validated AND, if applicable, step 7 has been successfully executed:
    • The Resource Centre's status is changed to suspended.
    • It is advised that the services of the Resource Centre are set to "production=N" "monitored=N" in the GOCDB.
    • The downtime is terminated. 
    • All this actions must be recorded in the master ticket.
  2. At this point the Resource Centre is no longer listed in the topBDIIs of EGI and cannot be reached by simply submitting a job. It might still be possible to directly access the Resource Centre for members of VOs which the Resource Centre supported. If hardware is closed down, the Resource Centre will need to address this, possibly informing these users that their data could be at risk.


9 RC
  1. Logs are to be kept at the Resource Centre, available for the period of time requested by the Grid Security Traceability and Logging Policy (90 days) after the status is set to suspended, in case of inquiries related to security incidents the period could be extended. Note:If the logs are saved elsewhere the services hardware can be disposed.
10 OC
  1. Resource Infrastructure Operations Manager is to communicate to EGI operations AND EGI CSIRT the end of the 90 days period. Revoke the roles of Resource Centre Administrator and people relevant to this Resource Centre in GOCDB and to the relevant CA if appropriate. Resource Infrastructure Operations Manager is to clean the VOMRS dteam server accordingly. In case there is no user left relevant to this very Resource Centre, the Resource Infrastructure Operations Manager has to inform his/her CA in order to close this entity officially to avoid keeping “ghost entities”.
  2. Site is closed in GOCDB
    • This action must be recorded in the master ticket
  • NOTE: People will have to separately handle any subscriptions to mailing lists which have been initiated by Resource Centre Administrator and which were not triggered by contact definitions in the GOCDB.
11 OC
  1. Master ticket is closed.