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.

Staged Rollout process

From EGIWiki
Revision as of 15:27, 2 February 2011 by David (talk | contribs) (Created page with '=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…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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. a. The ownership of the sw-rel ticket is changed to the SSO group “sw-rel-sr”. 3. The staged rollout managers “staged-rollout” SSO group is notified when the child ticket in queue “staged-rollout” is created. a. The “staged-rollout” ticket should contain the links to: i. Release notes, contains information about install/upgrade and configuration. ii. Bugs or issues fixed. iii. Documentation. b. The status of the ticket is “new”. 4. 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. a. The status of the ticket is changed to “open”. b. 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: i. <accept|reject> <NGI>-<Site-name> c. 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. 5. 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. 6. The EA teams do the staged rollout: install/upgrade, configure, and some tests as they see fit. a. 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. b. If a GGUS ticket is opened, this ticket should be assigned to the DMSU support unit, which will then routed it to the technology providers as they see fit. c. A link to the GGUS ticket is created in the staged rollout ticket. 7. 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. 8. Each EA team should fill the “staged rollout” templates after the last point, and attach it to the “staged-rollout” ticket: a. The name of the file should be: i. ea-<NGI>-<Site-name>-<MW stack>-<component>-<version>.EXT (doc, docx, odt) 9. The staged rollout managers: a. Collect all reports and may produce a summary report. b. 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. c. Insert a link to the Dec server ID of the reports. d. Write the outcome <ACCEPT|REJECT> in a custom field. e. Set the ticket status to “resolved”. 10. 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.

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 people 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>“