PROC02 Operations Centre creation

• Title: New NGIs creation procedure
• Document link: https://wiki.egi.eu/wiki/Operations:New_NGIs_creation
• Last modified: 22.10.2010
• Version: 2
• Policy Group Acronym: GOO/COD
• Policy Group Name: Grid Operations Oversight/Central Operator on Duty
• Contact Person: Małgorzata Krakowian, Marcin Radecki
• Document Status: APPROVED
• Approved Date: 26.10.2010
• Procedure Statement: The purpose of this document is to clearly describe the actions and the relative steps to be undertaken for integrating a NGI (or a group of NGIs) into the EGI operational structure.

Procedure for the creation and validation of a new NGI

The purpose of this document is to clearly describe the actions and the relative steps to be undertaken for integrating a NGI (or a group of NGIs) into the EGI operational structure. We call a “group of NGIs” a structure that contains sites from more than one country which is managed by one single operational structure (in terms of support, tickets assignment, etc.). From an operational point of view a single NGI or a group of NGIs (according to the definition provided above) are the same, and in the rest of the document both cases will be referred to using the word “NGI”.

This document is only relevant to operators of a stand-alone NGI or of a group of NGIs. It is irrelevant for NGIs that are operated as part of a group of NGIs.

Revision history

Version	Authors	Date	Comments
2.00	Małgorzata Krakowian, M. Radecki	2010-10-26	Approved by OMB
1.00	Małgorzata Krakowian, M. Radecki, V.Hansper et alt.	2010-08-17	Approved by OMB

Validation of NGI creation request

This document details the technical steps needed for the validation of an NGI.

The first step for validating an NGI (single or group of NGIs) is to be politically approved as an official partner of the EGI infrastructure. NGIs that are a partner of the EGI-InSPIRE project are already implicitly part of the EGI infrastructure.

After this step, the NGI needs to be technically validated. The Central Operator on Duty team - in charge of EGI oversight - is responsible for performing this validation. However, if the NGI is part of an ex EGEE-ROC structure which is still operating, and which is willing, then the ROC can perform the validation itself.

Political Validation

CASE 1. If an NGI is already represented within the EGI Council and is ready to move from an EGEE ROC to an operational NGI, we recommend that the NGI political representative within the EGI Council notifies the EGI Chief Operations Officer that the respective NGI is entering its validation cycle. At this point, the technical validation can start.

CASE 2. If an NGI is not represented within the EGI Council, and it is willing to be represented there, the NGI needs to submit a request for admission to the Council. After the NGI has been accepted by the Council, CASE 1 applies.

CASE 3. If a new NGI is not represented within the EGI Council and is not interested in being part of it, but would still like to be a consumer of the EGI Global Services, then an MoU must be established with EGI. Once an MoU is in place technical validation can start.

Technical Validation

• The Integration Process Coordinator (IPC) is the entity responsible of integrating a new NGI within EGI. The IPC can be the EGEE parent ROC of the NGI (if still operational), or COD.

• The NGI Operations manager(s) sends an email to the Chief Operations Officer (COO) that the Council was informed about the creation of a new NGI, and (if applicable) also that the Council has approved it. The NGI Operations manager(s) should also indicate the IPC responsible for the validation in the email.

• The Chief Operations Officer opens a GGUS ticket to the IPC to start the validation process.

How to start the integration process for an NGI (or NGI group)

• The integration of a new NGI starts when the COO opens an NGI validation ticket to the IPC (via GGUS).

• Once the COO ticket is filed, the IPC can start the validation process. In order to trigger the actions described in this document the IPC creates a set of new child tickets that are assigned to the individual partners that are responsible for the various validation steps. Thereby, the integration process should be as transparent as possible to all parties involved. The required actions are described below.

An example/template for the NGI creation ticket is provided here:

Subject: Creation of NGI_XXX


Required information for the creation of the NGI:
Management mailing list : management@xxx.org
NGI Operations manager contact data : Person Surname (email) +phone contact,
Deputy: Person Surname (email) +phone contact,

NGI security officer contact data : Person Surname (email) +phone contact,
NGI security mailing list : abuse@xxx.org

ROD team mailing list : ngi-support@xxx.org
NGI nagios monitoring system details : https://mon-ngi.xxx.org/nagios
Mailing list for GGUS tickets if using GGUS directly : xxxticket@xxx.org

The FAQ document for the NGI provided by the GGUS team is in the attached file (GGUS_1800_FAQ_for_NGI_xxx.pdf)
(see extra document provided)

New NGI prerequisities

Before opening an NGI creation GGUS ticket, the NGI should:

1. Decide whether to use the NGI's own help desk system or use GGUS directly. If the NGI wants to set up their own system they need to provide an interface for interaction to GGUS with the local ticketing system and follow the recommendations available at https://gus.fzk.de/pages/ggus-docs/interfaces/docu_ggus_interfaces.php.
2. Set the following contact points:
   1. Management mailing list
   2. NGI operations manager contact data
   3. NGI security officer contact data
   4. NGI security mailing list
   5. ROD team mailing list (including people responsible for monitoring and supporting the NGI infrastructure)
   6. Mailing list for GGUS tickets IF GGUS is used directly for the helpdesk system
3. Deploy an NGI Nagios instance if the NGI is going to run its own instance (see https://twiki.cern.ch/twiki/bin/view/EGEE/GridMonitoringNcgYaim and https://twiki.cern.ch/twiki/bin/view/EGEE/ValidateROCNagios)
4. Fill the FAQ document for the NGI. The template is provided by the GGUS team: https://gus.fzk.de/pages/ggus-docs/DOC/1800_FAQ_for_TEMPLATE.doc
5. Staff in the NGI that should be granted a management role (manager, deputy manager, security officer) should first register a user account in the GOCDB. The user registration procedure is described in the GOCDB user documentation at http://goc.grid.sinica.edu.tw/gocwiki/GOCDB_User_Documentation, section 3.1.1
6. Staff in NGI is familiar with Operational Procedures

NGI creation process steps

Some steps of the process can be done in parallel as they are independent, so all steps grouped within the same task number can be performed concurrently (several different child tickets will be created in order to speed up the process). The general idea is that these tickets must be closed before being able to move on to the next step.

Validation steps:

Step	Substep	Action on	Action
1		IPC	Verification of the validity of the request (were all needed data provided?)
2		IPC	Create child tickets in the order given as follows:
	1	GOCDB	Creation of a new NGI entry in the GOCDB (with no site attached). Include the following into the GOCDB ticket: NGI name: NGI_XXX (or NGI_GROUP_XXX) NGI management mailing list: foo@bar.org NGI security mailing list: NGI Operations manager: NGI security officer:
	2	Operations Portal	Enter the new NGI in the Operations dashboard (also add ROD mailing list)
	3	GGUS	Create a new support unit in GGUS : NGI_XXX NOTE: (attach the FAQ document for the NGI to this ticket.)
	4	COD	Certification of new ROD team – https://wiki.egi.eu/wiki/Procedure_to_handle_new_ROD_certification_GGUS_tickets Include in the GGUS ticket for Operational Documentation: Country NGI acronym ROD email list
	4	NGI_PL	Enter the new NGI in SAMAP (required for certification of new sites in NGI)
3		Dteam VO manager	Create a branch/group for NGI and assign DN of persons who will be responsible for managing it. How to assign the child ticket: assign the ticket to "VO support" after the selection of "dteam" in the concerned VO field This step is not blocking the process and can be done in parallel. It is required to finish this step before closing parent ticket.
4		The newly created NGI_XXX	Include the NAGIOS host in the GOCDB as a 'National-Nagios' service. (This step only applies to NGIs running an NGI Nagios instance)
5		[If the NGI was part of a ROC] IPC	Configure the NGI in the ROC Nagios instance
6		The newly created NGI_XXX	Final confirmation that the new NGI can start the operations
7		GOCDB	[If the NGI was part of a ROC] GOCDB transfers related sites from the source ROC to the new NGI structure. NOTE: If this is a Group of NGIs, please indicate the sites moving across to the new NGI in the ticket.
		The newly created NGI_XXX	[If the NGI wasn't part of a ROC] Newly created NGI_XXX can insert new sites
8		The newly created NGI_XXX	Inform regional VO managers to change VO scope from ROC to their relevant NGI or scope. This action require only confirmation from NGI manager that information was passed. Information which should be pass to VO managers: "The VO should appear in the cic portal : https://cic.gridops.org/index.php?section=vo, and the links provide a way to update the VO card if applicable. VO managers must ensure that the information there is correct."
9	OPTIONAL	The newly created NGI_XXX	All sites should be reconfigured according to the instructions at: http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_my_site_information change the old information from: SITE_OTHER_EGEE_ROC="XX" SITE_OTHER_GRID="EGEE" to: SITE_OTHER_EGI_NGI="NGI_XXX" SITE_OTHER_GRID="EGEE|EGI" This step can be performed at any time from this point.
10		The newly created NGI_XXX	Transfer all open operational tickets to the new NGI in GGUS.
11		Nagios team	Include the NGI level Nagios in the central ops-monitor Nagios instance. (This step only applies to NGIs running an NGI Nagios instance)
12		IPC	Validation process of the new NGI Nagios, as described at the step 5.3 of: https://twiki.cern.ch/twiki/bin/view/EGEE/ValidateROCNagios#Validation_Process. (This step only applies to NGIs running an NGI Nagios instance)
13		Nagios team	Validation that sites/NGI shown up correctly in Central DBs
14		[If the NGI was part of a ROC] Nagios team	Migrating alerts from ROC to NGI Nagios instance. (This step only applies to NGIs running an NGI Nagios instance)
15		IPC	Final checks by the IPC. (Were all steps taken and finished properly? Close the parent ticket.)
16		The newly created NGI_XXX	Final checks should be verified and then the information that the NGI is ready is broadcast by NGI officials. (This broadcast should be sent to VO managers and NOC/ROC managers) See the template below for an indication of the message content. Subject: NGI_XXX is operational Dear All, We would like to announce that NGI_XXX is now fully operational and that we have finished its integration procedure. All necessary operational teams and tools are established in our NGI and we are ready for production. This NGI is visible in all operational tools as NGI_XXX and is responsible for all <COUNTRY> sites. Best regards,