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 "PROC02 Operations Centre creation"

From EGIWiki
Jump to navigation Jump to search
Line 176: Line 176:
13 - [If the NGI is partner of a former ROC] Nagios team to perform: Migrating alerts from ROC to NGI Nagios instance. Completion of Step 5 is a pre-requisite.
13 - [If the NGI is partner of a former ROC] Nagios team to perform: Migrating alerts from ROC to NGI Nagios instance. Completion of Step 5 is a pre-requisite.


14 - [If the NGI is partner of a former ROC] IPC to perform: Final checks by the parent ROC. (Close a parent ticket.)
14 - IPC to perform: Final checks by the IPC. (Close a parent ticket.)


15 - Newly created NGI_XXX to perform: final checks and broadcast of the information by NGI officials.
15 - Newly created NGI_XXX to perform: final checks and broadcast of the information by NGI officials. (Broadcast should be send to VO managers and NOC/ROC managers)


<pre>
<pre>

Revision as of 08:21, 23 June 2010

--Tferrari 15:48, 21 June 2010 (UTC)

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 structures. 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 operated as part of a group of NGIs.

Revision history

Version Authors Date Comments
0.12 Małgorzata Krakowian, Tiziana Ferrari 2010-06-16 Migration to wiki page. Political and technical validation section.
0.11 Marcin Radecki, Małgorzata Krakowian, David Collados 2010-06-15 Nagios Box validation.
0.10 Marcin Radecki, Małgorzata Krakowian 2010-06-11 Update item 99953 and 99954
0.9 Marcin Radecki, Małgorzata Krakowian 2010-05-19 Update item 99953 and 99954
0.8 Marcin Radecki, Małgorzata Krakowian 2010-05-13 Update item 99953 and 99954 – Configuration NGI in Nagios
0.7 Marcin Radecki, Małgorzata Krakowian 2010-04-27 Update item 99953 and 99954
0.6 Guenter Grein 2010-04-26 Update item 99953
0.5 Marcin Radecki, Małgorzata Krakowian 2010-04-23 Adding step to inform ROC managers about new NGI creation and step which concerns ROD team creation
0.4 Marcin Radecki 2010-04-06 Changes related to NGI nagios box validation (not necessary yet) and renumbering of steps.
0.3 Marcin Radecki 2010-03-05 Proposed changes according to experience with creating NGI_PL
0.2 ROD Pole 3 2010-01-27 Refined procedure taking technical requirements in consideration
0.1 Guenter Grein 2010-01-12 First draft

Validation of NGI creation request

This document details the technical steps needed for NGI validation.

The NGI validation starts after the NGI (single of group of NGIs) has been politically approved as official partner of the EGI infrastructure. NGIs that are partner of the EGI-InSPIRE project are already implicitly admitted to be 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 of performing such validation, unless the NGI is part of an ex EGEE-ROC structure still operating, which is willing to perform the validation itself.

Political Validation

Text to be approved

CASE 1. If a NGI is already represented within the EGI Council, we recommend that the NGI political representative within the EGI Council notifies the Council that the respective NGI is entering its validation cycle. At this point, the technical validation can start.

CASE 2. If a 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 before being technically validated. After this step, CASE1 applies.

CASE 3. If a new NGI is not represented within the EGI Council and is not interested in being part of it, but still would like to be a consumer of the EGI global services, then a request of admission has to be submitted and approved by the Council. If approved, the technical validation can start. It is likely that in the future the signing of a MoU will be requested before validation can start.

Technical Validation

The NOC managers and COD mailing lists are notified by the NGI manager that the NGI is ready for technical validation.

CASE 1. If the NGI belonged to an EGEE ROC that is still operating, the NGI is validated by the respective ROC manager.

CASE 2. If the NGI didn't belong to an EGEE ROC, the COD is responsible of the NGI validation.

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

For integrating a new NGI the NGI representative should submit a GGUS ticket (https://gus.fzk.de/pages/home.php). The ticket should be assigned to a ROC parent to the NGI or COD who will act as a Integration Process Coordinator (IPC). 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 of the various validation steps. Hence the integration process will be as transparent as possible to all parties involved. The required actions are described in what follows.

New NGI prerequisities

Before opening a NGI creation GGUS ticket, NGI should:

  1. 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 of monitoring and supporting the NGI infrastructure)
    6. Mailing list for GGUS tickets if using GGUS directly as helpdesk system
  2. Deploy an NGI Nagios instance if NGIs 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)
  3. Fill the FAQ document for the NGI. The template is provided by GGUS team: https://gus.fzk.de/pages/ggus-docs/DOC/1800_FAQ_for_TEMPLATE.doc
  4. Decide whether to use an own help desk system or GGUS directly. If you want to set up your own system provide an interface for interaction of GGUS with a local ticketing system and follow the recommendations available at https://gus.fzk.de/pages/ggus-docs/interfaces/docu_ggus_interfaces.php.
  5. Anyone that should be granted a management role on a new NGI (manager, deputy manager, security officer) should first register a user account in GOCDB. The user registration procedure is described in GOCDB user documentation at http://goc.grid.sinica.edu.tw/gocwiki/GOCDB_User_Documentation, section 3.1.1

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:

1 - IPC to perform: Verification of the validity of the request

2 - IPC to perform: Broadcast of the information that new request was validated


IPC creating child tickets in the order given as follows:

3 - GOCDB to perform: Creation of a new NGI entry in GOCDB (with no site attached). (Wait until done.)

  • NGI name: NGI_XXX (or NGI_GROUP_XXX)
  • NGI management mailing list: foo@bar.org
  • NGI security mailing list:
  • NGI manager:
  • NGI security officer:

4.1 - CE ROC to perform: Configuration of the new entry in SAMAP (required for certification of new sites in NGI)

4.2 - Operations Portal to perform: Configuration of the new entry in the Operations dashboard

4.3 - GGUS to perform: Creation of a new support unit in GGUS : NGI_XXX (ticket with FAQ document for the NGI attached.)

4.4 - COD to perform: Certification of new ROD team – https://wiki.egi.eu/wiki/Procedure_to_handle_new_ROD_certification_GGUS_tickets

5 - The newly created NGI_XXX to perform: Include the NAGIOS host in GOCDB as a 'National-Nagios' service. (This step only applies to NGIs running an NGI Nagios instance) (Wait until done.)

6 - Nagios team to perform: Include the NGI level Nagios in the central ops-monitor Nagios instance.

7 - [If the NGI was part of a ROC] IPC to perform: Configuration of the NGI in the ROC Nagios instance

8 - The newly created NGI_XXX to perform: Final confirmation that the new NGI can start the operations

9 - GOCDB

  • [If the NGI is part of an EGEE ROC] to transfer related sites from the source ROC to the new NGI structure
  • [If the NGI is not member of a former ROC] to insert new sites

10 - Newly created NGI_XXX to perform: Transfer all open operational tickets to new NGI in GGUS.

11 - IPC to perform: 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. Completion of Step 5 is a pre-requisite.

12 - Nagios team to perform: Validation that sites/NGI shown up correctly in Central DBs

13 - [If the NGI is partner of a former ROC] Nagios team to perform: Migrating alerts from ROC to NGI Nagios instance. Completion of Step 5 is a pre-requisite.

14 - IPC to perform: Final checks by the IPC. (Close a parent ticket.)

15 - Newly created NGI_XXX to perform: final checks and broadcast of the information by NGI officials. (Broadcast should be send to VO managers and NOC/ROC managers)

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. NGI is visible 
in all operational tools as NGI_XXX and is responsible for all <COUNTRY> sites.

Best regards,