Staged Rollout process

TECHNICAL IMPLEMENTATION AND WORKFLOW

The SW release workflow has been described first in MS402, and progressed into the description given in the NSRW wiki: https://wiki.egi.eu/wiki/NSRW_IMPLEMENTATION_RT . The present document describes the part of the workflow corresponding to the “Staged Rollout” phase.

The staged rollout start when the state of the RT ticket in the queue sw-rel changes from InVerification to StageRollOut, this means that the SW component as passed the verification process.

It is assumed that the staged rollout repository is fixed for any given major release of any SW, this is publicly available in the repository and EGI wiki for Early Adopters. This state change triggers the following actions:

1. The SW packages are moved from the InVerification repository to the StageRollOut repository.
2. The sw-rel ticket creates a new child ticket in the staged-rollout queue.
   1. The ownership of the sw-rel ticket is changed to the SSO group sw-rel-sr.
3. (Staged Rollout Manager) The staged rollout managers staged-rollout SSO group is notified when the child ticket in queue staged-rollout is created.
   1. The staged-rollout ticket should contain the links to:
      1. Release notes, contains information about install/upgrade and configuration.
      2. Bugs or issues fixed.
      3. Documentation.
   2. The status of the ticket is new.
4. (Staged Rollout Manager) The queue staged-rollout has a custom field (dropped down) where the staged rollout managers select the EA teams to assign the staged rollout test.
   1. (Staged Rollout Manager) The status of the ticket is changed to open.
   2. (EA teams) Each EA team has to acknowledge the reception of the notification within 1 working day. Either by replying to the mail sent by the RT or directly in the ticket with:
      1. (EA teams) <accept|reject> <NGI>-<Site-name>
   3. (Staged Rollout Manager) The staged rollout manager will check the ticket and if there are no EAs accepting the staged rollout test, it will pool the

early-adopters-XXX.mailman.egi.eu mailing lists, and other (s)he see’s fit to get other EA sites.

1. (EA teams) The EA team has the option to put the service node into downtime in the GOCDB, special beta tag. This tag may be set only during the staged rollout phase, if/when the component is release into production, this tag (or downtime), should be removed from the gocdb.
2. (EA teams) The EA teams do the staged rollout: install/upgrade, configure, and some tests as they see fit.
   1. (EA teams) If the EA finds problems or issues, either they are clarified within the ticket by the staged rollout managers and other EA teams, OR , a GGUS ticket should be opened.
   2. (EA teams) If a GGUS ticket is opened, this ticket should be assigned to the DMSU support unit, which will then route it to the technology providers as they see fit.
   3. (EA teams) A link to the GGUS ticket should be created in the staged rollout ticket.
3. (EA teams) The service should ideally be exposed into production load/environment and users. This period may last between 5 to 7 days, but may be extended depending on the cases.
4. (EA teams) Each EA team should fill the staged rollout templates after the last point, and attach it to the staged-rollout ticket:
   1. (EA teams) The name of the file should be:
      1. ea-<NGI>-<Site-name>-<MW stack>-<component>-<version>.EXT (doc, docx, odt)
5. (Staged Rollout Manager) The staged rollout managers:
   1. Collect all reports and may produce a summary report.
   2. Create a document in the EGI Doc server with a given ID, which will contain all reports for the staged rollout of that component, as well as the summary report.
   3. Insert a link to the Dec server ID of the reports.
   4. Write the outcome <ACCEPT|REJECT> in a custom field.
   5. Set the ticket status to resolved.
6. (Staged Rollout Manager) When the staged rollout child ticket is set to resolved the parent ticket is notified, and it should get the outcome and the doc server id of the reports.

Naming conventions

• For the staged rollout, the following is used:
  • https://rt.egi.eu/rt/index.html
  • Queue name: staged-rollout

• Report templates:
  • Each Early Adopter has to fill a report, from the template:
  • https://documents.egi.eu/public/ShowDocument?docid=254

• The EA team names are SSO groups containing the members of each team:
  • ea-<NGI>-<Site-name>

• The custom fields needed in the staged-rollout queue are:
  • Drops down box containing all EA teams, on the EGI SSO: possibility to select several teams, the button Save Changes notifies those teams and they will be added to the AdminCC field.
  • Outcome of the staged rollout, drop down box with: <ACCEPT|REJECT>.

• The title of the ticket is of the form:
  • “Staged Rollout <SW stack-MajorVersion> <COMPONENT> <VERSION> <OS> <ARCH>”
  • Examples:
    • Staged Rollout CA 1.38
    • Staged Rollout EMI-1.0 SE-DPM_mysql 1.8.0-1 SL5 x86_64

• Two persons per SW stack should ideally compose the staged rollout managers group:
  • Glite
  • ARC
  • UNICORE
  • Globus
  • Operational Tools

• The name of the file should be:
  • Filename: ea-<NGI>-<Site-name>-<MW stack>-<component>-<version>.doc(odt)

• The staged rollout manager will provide a summary and the name of the file is:
  • Filename of summary: summary-<MW stack>-<component>-<version>.doc(odt)

All reports and the summary will be in: https://documents.egi.eu with a given ID, that will be referenced in the respective rt ticket.

• The description in the document database should have the following naming convention:
  • Staged rollout <MW stack> <component> <version>

---

Back Staged-Rollout