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.

Difference between revisions of "PROC13 VO Deregistration"

From EGIWiki
Jump to navigation Jump to search
(Remove deprecated content)
Tag: Replaced
 
(159 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Template:Op menubar}}  
{{Template:Op menubar}} {{Template:Doc_menubar}}
{{Template:Doc_menubar}}  
[[Category:Deprecated]]
{{TOC_right}}
{| style="border:1px solid black; background-color:lightgrey; color: black; padding:5px; font-size:140%; width: 90%; margin: auto;"
 
| style="padding-right: 15px; padding-left: 15px;" |  
{| border="1"
|[[File:Alert.png]] This page is '''Deprecated'''; the content has been moved to https://confluence.egi.eu/display/EGIPP/PROC13+VO+Deregistration  
|-
| '''Title'''
| ''VO Deregistration Procedure''
|-
| '''Document link'''
| [https://documents.egi.eu/document/971]
|-
| '''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<br>
|-
| '''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 [[Glossary|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 [https://www.egi.eu/infrastructure/Resource-providers/index.html web site]
*A list of EGI Operations Centres with their respective contact information is available from the [http://go.egi.eu/operations-centres 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 [http://operations-portal.egi.eu/vo/rd Operations Portal].
*The VO managers and their contact information for a specific VO can be retrieved from the [http://operations-portal.egi.eu/vo Operations Portal].
 
= Actions and responsibilities  =
 
== VO Supervisor (COO)  ==
 
== VO Manager (if existing) ==
 
== VO's and VO managers  ==
 
#give the users the relevant information about the decommissioning (deadlines, involved resources, files, how to handle it)
#follow-up and support users in their file migration procedures until the deadline
#inform Resource Centre about the status of the migration(s)
 
<!--(<span style="background:#FFFF00">Tristan: if the VO is not responsive any more then the decommissioning could happen after x reminders. Res: We'll need to specify this in more detail.)
</span> -->
 
== 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
 
{| cellspacing="0" cellpadding="5" border="1"
|-
! #
! Responsible
! Action
|- valign="top"
| 1
| VOM (alternatively VOM)
|
# Open a GGUS ticket to begin the deregistration process. The ticket should contain the following information:
#* A link to the master GGUS ticket opened at point 1
#* 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
 
|- valign="top"
| 2-a
| VOM
|
(Optional step)
# Provide a snapshot of the resources supporting
#* List of grid services
#* List of files registered in the VO's LFCs
|- valign="top"
| 3
| RC
|
#Send a broadcast to all the VO users, specifying:
#* 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
# If there are other VOs accessing the VO data
 
|- valign="top"
|3bis
| VOU
|
# 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.
#* 
|- valign="top"
| 4
| VOM/VOS
|
#At the end of the time window
 
|- valign="top"
| 5
| RIP
|
#Communicate to EGI operations (COD) the start of the 3 month decommissioning period.
#The Operations Centre staff should check the reason of possible bottlenecks from the past experience: Eg: make sure that the communications flow from Resource Centre to VOs is correctly performed.<br>
 
|- valign="top"
| 6
| RIP
|
If the Resource Centre has storage elements (SEs)&nbsp;:
 
*Once the Resource Infrastructure Operations Manager has received confirmation that the Resource Centre's SEs are closed for write access, he opens N child tickets of the procedure's ''master ticket'' to each of the N VO managers of the N VOs the Resource Centre supported.
*The VOs are given up to 4 weeks - or the amount of time agreed in step '''3 bis''' - to retrieve their data from the Resource Centre. During these 4 weeks, the Resource Centre should make sure that the SE works for the different VOs to allow them to retrieve their files. The VO managers can specify any specific requirements in their child ticket. For instance:  
**Request in the child ticket from the Resource Centre Operations Manager the time limit needed to retrieve data.
**Request from VO central services admins the list of LFNs/DNs still having SURLs on SEs at that Resource Centre.
**VO Manager MUST communicate to the Resource Centre - if possible using the GGUS child ticket - when the data moving is completed.
 
|- valign="top"
| 7
| RIP
|
#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.
 
<br>
 
|- valign="top"
| 8
| OC
|
#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.&nbsp;
#*All this actions must be recorded in the ''master ticket''.
#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.
 
<br> <!--|- valign="top"
| 9
| OC
|
#After one week, the status of the Resource Centre is set to ''closed''. The Resource Centre can then be considered as ''experimental'' or however the parent Resource Infrastructure Provider considers appropriate. Direct notifications through the Resource Centre Administrator’ roles within EGI will no longer occur.
#*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.
 
(Peter: Imho, the whole step can be removed (the site is closed three month after this step), I would attach the mailing list subscription to another step. 9-12-2011)<br> 
 
<br> -->
 
|- valign="top"
| 9
| RC
|
#Logs are to be kept at the Resource Centre, available for the period of time requested by the [https://documents.egi.eu/document/81 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.
 
|- valign="top"
| 10
| OC
|
#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”.
#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.<!--(<span style="background:#FFFF00">Vera: Helene, I'm really not sure that this is the right place for these steps. Revoking the site admin roles should have happened in step 6.  Similarly with removal of dteam roles/entries.</span>) (<span style="background:#FFFF00">I think that as long as the site is "active" somehow the roles are needed to let them access op.tools. 7-12-2011 </span>)-->
|- valign="top"
| 11
| OC
|
# ''Master ticket'' is closed.
|}
|}

Latest revision as of 12:04, 8 April 2022