Document control

AreaRDM
Procedure status

FINALISED

Owner

Catalin Condurache

Approval status

APPROVED

Approved version and date

v9  

Statement

An emergency release consists in the releasing of one product, or a set of products, with the targeted goal of solving a specific problem that affects the EGI infrastructure. To qualify for an emergency release the problem should be classified in at least one of the following categories:

  • A critical security patch
  • A critical bug affecting multiple resource centres

Emergency releases are deployed by the services providers and apply to the services listed in the EGI Service Portfolios that are owned by the EGI Foundation.

Dissemination Level

TLP:WHITE - Public

Overview

This procedure is meant to cover releases for which a simplified planning/testing/deployment phase is established, as their deployments are required to fix a specific issue classified as a critical security vulnerability or critical software bug affecting multiple resource centres part of the EGI infrastructure.

A Jira ticket coming from CHM is used to orchestrate the complete release and deployment.

Once the release will have been deployed feedback will be added to the Jira ticket and re-assigned to CHM so that they can review it.

Definitions

Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

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

  • Change Owner: The person in charge of the change, following it through from initial planning to implementation and review. Initiates the Release procedure by marking a CHM ticket as ready to be released, assigning it to RDM.
  • Release Owner: The person in charge of the release, control and coordinate the activities in the lifecycle of a specific release.
  • RDM Staff: Oversees all the process and may provide further people for testing the service or service component. Usually it's the SDIS team.
  • CRM Staff: Will be informed of the release so that they can interface with customers if needs be.

  • Service Supplier: Team responsible for the actual development, release and deployment of the service or service component.

  • NOC-Managers: Are informed regarding the release of the new service or service component.

  • CAB: Change Advisory Board is a group of technical and strategic experts (membership decided by SSB) who are tasked with reviewing proposed change requests and reviewing them and approving or rejecting the changes.

Triggers

CHM1 Manage changes including emergency changes

Steps

 In case the release has to be canceled at any point in time, the last step will be triggered.
Step# ResponsibleActionPrerequisites, if any
1.

Change Owner

Updates Jira ticket assigned to CHM status to mark it as accepted for an emergency release.Change has been accepted by CHM as an emergency change.
2.RDM Staff

Appoint a Release owner, that will coordinating the release with the support of the RDM Staff.

The ticket is assigned to the Release Owner.


3.

Release Owner

RDM Staff

Ensures that the ticket contains the following information, and interacts with Service Provider to collect it:

  • Name of the service or service component;
  • Date of release;
  • Current version of the service;
  • Version of the service to be released;
  • Release notes;
  • Suggested deployment date;

This information is also meant to capture the CI baseline.

Gives green light by updating the ticket.


4.

Service Supplier

Register a downtime for the service in GOCDB, using 'WARNING' if no downtime is expected. The description field should include the Jira ticket link (useful in specific cases, during audits, for easy access by entitled people).


5.Service Supplier

Deploy the release.


6.

Release Owner

RDM Staff

Informs NOC-Managers by email about the emergency release and affected service or service component.

Informs CRM about the emergency release by sending a mail to ucst [AT] egi.eu and providing a link to the Jira ticket so that they can provide feedback if needed.


7.

Release Owner

RDM Staff

If the release took place, waits for a week to have confirmation that new release fixed the critical problem.

Comments the Jira ticket to provide feedback about the release.

Re-assigns the Jira ticket to CHM so that it can be reviewed according to CHM1.


Table of Contents