Locked History Actions

OPS/FAQs/SE_decommission_guidelines

SE Decommission Guidelines

This document summarizes common sense guidelines for the decommission of a VO (or several VOs) supported in a site Storage Element. This guidelines were collected BEFORE there was a general EGI procedure. That general procedure is now available in https://wiki.egi.eu/wiki/PROC12

Introduction

As a general good practice, during the decommissioning procedure of a SE, site administrators should try to bring VO administrators / VO support on board, and ask them to perform all the associated data management activities as described in the VO Centred SE decommission section.

Case the VO administrators / VO support teams do not reply or can not perform the necessary actions, site administrators should try to trigger individual users with stored files at their Storage Elements using the guidelines from the User Centred SE Decommission section.

VO Centred SE Decommission

  1. Contact the VO administrators / support (check the VO ID Card for the VO contacts) clarifying what you want to do:

    1. If the VO will be permanently decommissioned from the site SE, ask for the possibility for the VO support team to bulk-migrate the data to an SE external to the site. This procedure should include the file migration and changing the SURLs registrations in the VO catalogue. Case the VO provides a GGUS support unit, all the communication should be established via a GGUS ticket.
    2. If the VO will be supported under a new site SE, the site administrator should consider the possibility to migrate the current VO files from the site SE under decommission to the new site SE, preserving all the paths, if possible. The VO support team would then have to update the SURLs registrations in the VO catalogue.
  2. Case the VO Administrators do not accept, or do not reply in a reasonable period of time, start the User Centred SE Decommission. Otherwise, continue with the current procedure.

  3. Negociate a start time and a period for the task execution with the VO support teams.
  4. Announce that the SE will be decommissioned using the EGI broadcast tool, and selecting the impacted VO Admin and the VO users. The message should include:

    1. The start time for the SE decommission.
    2. The deadline for SE decommission.
    3. That the VO Administrator will take care of the migration of files
  5. If a GGUS ticket was opened to the VO Support, add the EGI broadcast link to the GGUS ticket.
  6. Once the start time has been reached, put your SE in read-only mode for that specific VO (if possible).
  7. Check the status of the situation with the VO support teams once the deadline has been reached.
  8. Send a final broadcast when the SE decommission procedure has finished.
  9. Remove the SE from the site information system (site-BDII) and from GOCDB

User Centred SE Decommission

  1. Announce publicly that the site SE will be decommissioned using the EGI broadcast tool selecting the VO Admin and the VO users which will be impacted. The message should clearly state:

    1. VO Administrators have been contacted
    2. Users are responsible for removing the files from the site SE
    3. A deadline for users to perform the file migration.
  2. Put your SE in read-only mode for that specific VO (if possible)
  3. Try to gather a list of SURLs, the corresponding LFNs (if you know them) per VO and User, and put that info available in a web server that you can link in the previous message. Since the task of gathering this info is difficult, it is something not mandatory but a best procedure to follow if possible. There is the LFCBrowseSE tool (developed by our UPV colleagues) that can help on that task.

  4. One week before the deadline is reached send a 2nd broadcast.
  5. Send a final broadcast when the SE decommission procedure has finished.
  6. Remove the SE from the site information system (site-BDII) and from GOCDB