TeraGrid Resource Decommission
From TeraGrid Wiki
Resource Providers (RPs) should use the following process to decommission TeraGrid compute and storage resources.
Allocations and POPS
A resource should be removed from POPS (and thus the allocations process) when the RP no longer wants to accept new allocations on the resource. The RP should notify the Allocations Coordinator (Kent Milfeld <firstname.lastname@example.org>). Because of the lead time for the allocations process, this must be done approximately 3 months prior to the time the resource should appear on the POPS list for allocations.
In general, the allocations team asks RPs (via the allocations-wg) to review, confirm, and update their resources listed for allocations once per quarter, just prior to opening POPS to accept submissions for the next TRAC meeting.
Operations and Security
- How to remove a resource or site from the security incidence response process? As each RP manages their own security on resources, outside of the RP itself, no change is necessary. Should the RP site security contact deem any information of interest to the Security Working Group and/or have requests for staff to be removed from security mailing lists, should no further TG resources remain at the site post decommission, they are welcome to send an email to the general Security working group mailing list security-wg (at) teragrid.org
- How to deactivate INCA monitoring of a resource? When a resource is no longer registered in central information services it will automatically trigger email to the Inca group who will turn off monitoring. Questions or problems can be directed to inca (at) sdsc.edu
The Resource Catalog is where RPs can notify users of impending decommissioning dates. When a resource's end date is known (or its status otherwise changes), the RP's documentation coordinator should update the status and end date in the Resource Catalog. This can be done as far in advance as the RP deems reasonable, to give users ample opportunity to plan their move to other resources.
The RP should submit a help ticket to confirm when they no longer wish the resource to appear in the TGUP System Monitor. The resource will be removed from the TGUP Add User form when an end date is entered into the TGCDB (see next item).
When a resource's end of service in TeraGrid is known, the RP should submit a ticket to email@example.com with that date. This can be done as far in advance as the RP has the relevant information.
Software Integration and Information Services
TeraGrid HPC systems and storage resources advertises which capability kits they offer using the CTSS 4 TeraGrid Core Integration capability kit's (MDS) information service. This information is aggregated and stored in central information services where it can be accessed by user documentation, the portal, science gateways, and other software systems.
Total resource deactivation
When a computation or storage resource is going to be removed from the TeraGrid and will no longer offer any capabilities to users, follow the deactivation instructions in the Core kit:
Note that simply deactivating the local (MDS) information services will not remove centrally stored information about a resource.
Partially resource deactivation
If a resource is being partially deactivated go to the resource's Core kit etc/registeredkits.conf file and comment out all the kits that are no longer supported. Kits that are still available post-production should have their SupportLevel and SupportGoal set to "retiring". Once all capabilities are no longer supported, follow the "Total resource deactivation" procedure above.