EGI-InSPIRE:Feedback from M. David

Workflow staged-rollout

This is slighlty altered version which is in MS402 V6

could be implemented by a combination of custom fields for the tickets in the staged-rollout queue and custom scrips triggering actions on changes of the ticket status or custom fields status.

Custom fields

"Status" (select one value) - Certified - Verified - Rolling-out - Grace-period - done (this is the final state and will close the ticket)

"Repository URL" : will point to the staged-rollout repo, can be a yum conf, or apt, the repo dir itself (not _all_ packages) this repo should contain "only" the new/updated packages. This should be a "delta" repo meaning that the EA should have configured the production repo plus this additional one (do you agree Kostas?), do we need interface here with the repo to get the metadata containing this url?

"Outcome" (select one value) - Success - Warning - Reject this should be set by the staged-rollout manager when he sets the "Status" to "done", it's obligatory.

"Assigned" (select one value) - Repository-managers - Technical-unit (the group doing verification) - Staged-rollout (the staged-rollout managers, the SSO group contains really only the managers/coordinators) - early-adopters-{glite|unicore|arc|globus|opstools}

Milos

"Now, I have a number of questions and notes. 1. Are there any actions in the process that are going to be done automatically towards RT? Are there some other services going to talk to RT in this process? In other words is there anything in the process that would require some RT interface other than the web UI or sending email to the staged-rollout queue (e.g., some sort of web service)? I have not figured out anything like that from the workflow description in the deliverable. On the other hand such a requirement makes quite a lot of sense to me."

There is at least the following, certain actions on the RT ticket will trigger events in the repository, for example the passage of the packages from unverified -> staged-rolllout repository directories should be triggered by setting the RT "Status" from Certified ->Verified so there is RT -> repo we will have to figure out if there is need of repo -> RT triggers

Ticket LifeCycle

1. The SW Provider creates a Ticket in GGUS accompanied with all the necessary info:
   1. Release notes, or the link to them. The release notes should link to the advisory written by the Software Vulnerability Group (SVG), in the case of a software vulnerability.
   2. Changelog, or the link to it. This can be already provided either inside the package or be part of the release notes.
   3. Certification report(s) (from the agreed quality assurance documentation and tests) or a link.
   4. Link to documentation: users manual, system administration manual, etc. The documentation should be updated if applicable, for example if the release introduces new functionality.
   5. Links to all bugs, issues, features in this new release. This can be already provided either inside the package or be part of the release notes.
   6. The URL of the SW provider repository. Either this is agreed and documented apriori, or should be given in the GGUS ticket so that the EGI repository managers can download the packages.
2. The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“
3. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
4. The Repo Processes the ticket
   1. Downloads the software bundle and puts it on the “Unverified” Repository
   2. The Repo parses the attached xml
   3. Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
      1. Upon success: The Repo updates the RT setting the RepoStatus of the ticket to “Unverified” + the URI where the new software can be found, etc.
      2. In case of a failure: The Repo updates the RT, setting the RepoStatus of the ticket to “Failed”, plus it updates the ticket with a comment that contains the information related to the failure
5. In both 4.3 cases, the RT Notifies the EGI Technology Unit Group (i.e the Ticket is Assigned to the EGI TUG):
   1. Verifies the new version. This includes the verification of all information provided according to point 1.
      1. If the verification is successful the packages are moved into the "Staged Rollout" repository.
      2. If there are problems or issues, then the component should be rejected in which case the RT ticket "Outcome" is set to "Rejected" and the "Status to "done. At this point a notification to the GGUS ticket is sent with the resulting value of "Rejected", whereby the Software Provider is notified.
   2. Inserts the URL of the repository or the URL of all the packages in the RT ticket. This will be used later by the early adopters to preform the staged-rollout.
   3. Sets the status of the RT ticket to "Verified". At this point the ticket will be assigned to "staged-rollout" group which is thus notified that new packages are ready for the staged-rollout.

MDavid: when the tech unit changes the RT ticket "Status" Verified->Rolling-out it will trigger in the repo the passage of the packages from Unverified -> Staged-rollout repository. The Tech unit should "Assigned" the ticket to "Staged-rollout", that's how the staged rollout managers are notified and take over the ticket.

1. If the TUG team decide that the release it is ready to move to stage-rollout phase, the RepoAction field of the ticket it is marked as MoveToStageRollOut
2. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
3. The Repo Processes the ticket
   1. Move the SW to stage-rollout
   2. The Repo updates the RT setting the RepoStatus of the ticket to “Stage-Rollout” + the URI where the new software can be found, etc.
4. RT Notifies the Staged-Rollout managers
5. If everything it is OK, the Staged-Rollout managers change the RepoAction field to “MoveToProduction”
6. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
7. The Repo Processes the ticket
   1. Move the SW to production
   2. The Repo updates the RT setting the RepoStatus of the ticket to “Production” + the URI where the new software can be found, etc.

…. and the life goes on ….

...