Document control

AreaEGI Federation Operations
Procedure status

FINAL

OwnerAlessandro Paolini 
ApproversOperations Management Board
Approval status

APPROVED

Approved version and date

v9,  

Statement

A procedure describing how to decommission a Virtual Organization currently registered in the EGI infrastructure.

Next procedure reviewupon request

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments

 

Alessandro Paolini copy from PROC13_VO_Deregistration in EGI Wiki. Updated the definitions section. Updated some links. Updated step 4: it was put in the same step the action to open a GGUS ticket for disabling the VO from its attribute management service.

 

Catalin Condurache Step 8 from VO Deregistration procedure (Open a GGUS ticket to "Operations" support unit requesting the status change of the VO to "DELETED") removed (no longer needed since the main ticket is assigned to Operations)

 

Alessandro Paolini 

as suggested in IMSIS-320 - Getting issue details... STATUS , the VO is automatically removed from the AppDB when it is decommissioned in the Operations Portal, so there is no need to open a ticket to the AppDB any longer.


Table of contents

Overview

The document describes the process of permanent de-registration of Virtual Organisations (VOs) from the EGI Infrastructure.

The focus of this document is on the tasks that VO representatives and the EGI operators have to accomplish in order to de-register the given VO.

As a result of this procedure, members of the given VO will not be able to access EGI resources (e.g. HTC, storage, and cloud) assigned to it.

This procedure applies to VOs currently registered in the EGI infrastructure.


The procedure workflow is composed by two processes:

  1. The validation of the request
  2. The de-registration

The second part is performed only if the de-registration request is accepted; if the request is rejected, the VO status is not modified by this procedure.

Definitions

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

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.

  • Check-in - EGI Check-in is a proxy service that operates as a central hub to connect federated Identity Providers (IdPs) with EGI service providers. Check-in allows users to select their preferred IdP so that they can access and use EGI services in a uniform and easy way.
  • PERUN - It is an Attribute Management solution. Perun covers management of the whole ecosystem around the users' identities, groups, resources, and services. Perun is well suited for managing users within organizations and projects, managing access rights to the services. Perun can manage any cloud platform in the domain of human resources due to his unique ability to push data of each Perun user into several cloud platforms, for example OpenStack or OpenNebula. As far as human resources are concerned, Perun is able to manage account creation and account extension. 
  • 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 EGI Helpdesk Service where users can create either incidents or service request tickets related to services provided by the EGI Infrastructure. 

Entities involved in the procedure

The main players participating in the VO deregistration procedure are:

  • VO manager (VM): person who is responsible for initiating the registration process.
  • VO supervisor (VS): person delegated from the EGI Operations team to handle the process on behalf of EGI project and is responsible for the approval of VO registration requests.
  • VO users (VU): members of VO
  • NGI Operations Manager: person in charge of National Infrastructure

Steps

Request validation

The following entities can submit a deregistration request for a VO through a GGUS ticket:

  1. VO Manager (VM)
  2. VO Supervisor (VS)
  3. VO User (VU)
  4. NGI Operations Manager
#ResponsibleAction
1Requester

Submit a GGUS ticket, specify in body of the ticket: "Please assign to the Operations Support Unit", including the de-registration request.

The ticket must contain the following information:

  • Role of requester (from the list above)
  • Motivation of the request
  • Assessment of the VO activities in the past year: A request submitted by the VO Manager does not require an assessment of the VO usage
2VS
  1. Validate the request
    1. Validate the requester identity
    2. If the requester is the VO Manager, the request is accepted, and next steps of Request Validation can be skipped
    3. If the requester is another entity, the following steps must be performed
  2. Communicate to the National Initiatives managers that a request has been submitted
3VS

Assess the VO activities during the last 12 months.

To accept the request the requirements are:

  • The VO has not produced accounting data for more than one year. Data available on the Accounting Portal (HTC and Cloud views)
4VSNotify the VO Manager about the pending request of VO decommission:
  • Open a GGUS ticket vs the VO support unit (if available).
  • Contact directly the VO Manager using the contact in the VO ID card


Both GGUS ticket and the mail sent to VO Manager must contain the following information:

  • Details of the request
  • The deadline to provide feedback on the request (min 1 month).
5VMVO Manager should discuss the VO deregistration request within the community and provide a feedback in the GGUS ticket or via email, within the deadline.
  • If the community still needs the VO, VO Manager should provide the motivations to reject the decommissioning
6VSRecord in the GGUS ticket the decision to approve or reject the request
  1. The request can be approved if:
    • The VO Manager did not reply and s/he did not provide any feedback before the deadline
    • The VO Manager agrees with the proposal
      • The GGUS ticket can be used for the de-registration procedure
  2. The request must be rejected if:
    • The VO Manager provided feedback and motivations to reject the decommissioning

VO Deregistration procedure

This procedure is performed only if the request is accepted.


#ResponsibleAction
1

VM (or VS)

Open a GGUS ticket to begin the deregistration process (or answer to the ticket used for the request validation).
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/Perun/Check-in support decommission
    • Expected date for the Helpdesk support unit decommission


Ticket SHOULD be assigned to the "Operations" support unit in GGUS

2

VM (or VS)

  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 de-registration (minimum one month from the broadcast)
    • The VOMS/Perun/Check-in support is being stopped in one month (minimum), after end of support users will not be able to get credentials to access the infrastructure services
    • VO Users may ask for an extension of the de-registration timeline within one month. The request SHOULD be supported by technical reasons (e.g. the amount of data stored in the storage elements is too big to be moved within the end of the procedure.
  2. If there are other VOs accessing the VO data (and only if VO Manager 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 VO Manager to retrieve the relevant data
3

VM (or VS)

After 2 weeks resend broadcast to the VO users
  • If users did not ask for an extension, send a broadcast as a reminder (with the same information as in step 2)
  • If users asked for an extension, send a broadcast with the new timeline
4

VM (or VS)

After one month period (or longer period, if extended) create a GGUS ticket to request to disable the VO from the VOMS server supporting the VO / Perun / Check-in. 

Assigne the ticket to:

  • the RC hosting the VOMS server if the VO was using VOMS
  • "Perun" support unit if the VO was using Perun
  • "Check-in" support unit if the VO was enabled in EGI check-in

The information can be found in the VO ID card on Operations Portal.

5

VM (or VS)

Broadcast to RCs that the VO is going to be decommissioned

Adding the following instructions/information:

  • The link to the GGUS master ticket
  • If the RCs are supporting the VO, they are free to decommission any allocated resources and stop any VO-specific activity  
  • Logs have to be maintained as long as requested by the Security Traceability and Logging Policy

6

VM (or VS)

Open a GGUS ticket  to "GGUS" support unit requesting to remove the VO from the "concerned VO" field if it was previously added

7VS

Decommission the VO using the Operations Portal by pushing the related button (Decommission VO). The VO status will be temporary reported as "leaving" before the VO being definitely deleted.

The VOs using cloud resources appear on AppDB and by decommissioning them in the Operations Portal they will then be automatically removed from the AppDB: you may in case verify that this properly occurred.

8

VM (or VS)

Close the main ticket
  • This step concludes the deregistration procedure
Additional notes
  1. VO Manager and VO users MUST manage their tools (such as mailing lists, monitoring tools, portals) separately, and they are out of the scope of this procedure
  2. If the VO provides tools for the users access to the grid resources (for example science portals or user interfaces), logs MUST be retained as requested by the Security Traceability and Logging Policy