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 "EGI-InSPIRE:NSRW New Software Release Workflow"

From EGIWiki
Jump to navigation Jump to search
(Created page with ' == Work Flow == == MetaDATA == NRMS New Release MetaDATA schema == Ticket Status Values == == Other Info == === Feedback from M. David === Workflow staged-rollout Thi…')
 
Line 1: Line 1:
== Work Flow ==
== Work Flow ==


Line 8: Line 7:
== Ticket Status Values ==
== Ticket Status Values ==


== Other Info ==
== Related Info ==


=== Feedback from M. David ===
=== Feedback from M. David ===

Revision as of 13:00, 22 September 2010

Work Flow

MetaDATA

NRMS New Release MetaDATA schema

Ticket Status Values

Related Info

Feedback from M. David

Workflow staged-rollout

This is slighlty altered version which is in MS402 V6 after S. Newhouse comments/review I put additional comments and try to answer to Milos, Ales and Kostas

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. MDavid: OK, Correct

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


1. Software providers

1.1. A new version of a component has been produced and certified by the software provider. At this stage or earlier, the software provider creates a new ticket in the βÄ€staged-rolloutβÄù RT queue in the state βÄ€CertifiedβÄù. This ensures that the software provider is notified on any change in state of the ticket. This ensures a close and direct contact or a quick action if, at any step, there is a problem or issue with the component.

MDavid: There is one person of the SW provider team which will create the ticket and is the "Requestor", upon ticket creation he can put into "Cc" other members of the product team which he see fits to acompany the process (does this sound resonably?)


1.2. The software provider has to provide the following information in the RT ticket, upon ticket creation:

1.2.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.

1.2.2. Changelog, or the link to it. MDavid: I agree with Ales, this piece should be already provided either inside the package or be part of the release notes.

1.2.3. Certification report(s) (from the agreed quality assurance documentation and tests) or a link.

1.2.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.

1.2.5. Links to all bugs, issues, features in this new release. MDavid: I agree with Ales, this piece should be already provided either inside the package or be part of the release notes.

1.3. The ticket is then assigned to the EGI Repository Manager. I think that: the ticket creator (SW provider) sets the "Assigned" field to "Repository-managers", this is how the repo managers will get notified that they should trigger the upload of new packages into the egi repo "Unverified" and proceed to step 1.4

1.4. The EGI Repository Manager pulls the packages (rpm, deb, tar, etc.) into the EGI repository called βÄ€UnverifiedβÄù, and after automatic checksum verification they set the relevant ticket in RT to βÄ€UnverifiedβÄù If this step fails, the process is repeated.

1.5. The EGI Repository team, assigns the ticket to the EGI Technology Unit group, after step 1.4 is successfully accomplished. MDavid: I think that 1.4 and 1.5 have to be merged into: 1.4 The EGI Repository Manager pulls the packages (rpm, deb, tar, etc.) into the EGI repository called βÄ€UnverifiedβÄù, and after automatic checksum verification they set the "Assigned" field to "Technical-unit", the technical unit is thus notified and one of the persons from this group set himself as "owner" of the ticket. If this step fails, the process is repeated. Again that is how the EGI TechUnit knows that there is a sw component to be verified.

2. EGI Technology Unit (MU) [R1]:

2.1. Verifies the new version. This includes the verification of all information provided according to step 1.2.

2.2. If the verification is successful the packages are moved into the βÄ€Staged RolloutβÄù repository. If there are problems or issues, the Software Provider is notified immediately. After discussion a countermeasure will be agreed upon to solve the issue at hand. This measure can include the rejection of the component which case the RT ticket "Outcome" is set to βÄ€RejectedβÄù and the "Status to "done.

2.3. 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. MDavid: see earlier comments, not ot put all the packages(or urls to it), just the "top level" url or yum/apt config

2.4. 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.

3. EGI Operations Unit (OU):

3.1. The βÄ€staged-rolloutβÄù group notifies the corresponding βÄ€early-adoptersβÄù group βÄ™ through a ticket βÄ™ that a new version of a given middleware component or operational tool is ready for staged-rollout. MDavid: the staged-rollout manager should set one of the person as "owner" of the ticket, and "Assigned" to "Early-adopter-XXX", in this way all members of the early-adopters-XXX sso group are notified. The staged rollout manager can set the "Time left" one day, or this be done authomaticaly.

3.2. Any early adopter participating staged-rollout of the relevant component should enter the RT and βÄ€acceptβÄù the ticket within one working day after the notification.

3.2.1.The first early adopter βÄ€acceptingβÄù the ticket, sets its status to βÄ€rolling-outβÄù. The EA may record in the ticket additional comments during the staged-rollout process. MDavid: I will change this to, the "Status" is already βÄ€rolling-outβÄù.


3.2.2. Any other early adopter can also βÄ€acceptβÄù the same ticket.

3.2.3. Any number of early adopters can contribute to staged-rollout for any given component.

3.2.4. From this point forward, only the early adopter teams that accepted the staged-rollout for a given component, will receive notifications from that ticket, as well as the software providers.

MDavid: ok the tricky part. It's one person of one of the EA teams which accepts the test, so this could be a custom field with a check-box? saying accept, then a child ticket is created having all information as the parent ticket, the owner of the "child" is that person, which can put other persons of his team on Cc. The parent will have the reference to all childs, so we now how many there are and can quickly browse them. The child will have only 2 "Status": "rolling-out" and "done" which will close that ticket, it will have an obligatory "Outcome" It will have a "wikitext" field for the report. The report will be "exported" to the parent upon closure of the child. Below the "simple" template of the report:


Site Name: Release notes: <OK|WARN|FAIL> Installation/upgrading: <OK|WARN|FAIL> (Re)-configuration with YAIM: <OK|WARN|FAIL> Functionality: <OK|WARN|FAIL> Comments:


OK, does it make sense? I think it covers most of what comes in the next steps

3.3. The βÄ€staged-rolloutβÄù group checks after one day, if the ticket is in the state βÄ€rolling-outβÄù. If it's missing, the group will take action. This might be, by getting in contact with partners not yet in βÄ€rolling-outβÄù state to solicit the start of staged rollout or by calling for new partners.


3.4. A given early adopter should primarily βÄ€acceptβÄù staged-rollout for the components it has officially committed to. However, early adopters are encouraged to participate to staged-rollout of additional components, even if not on a regular basis.

3.5. It is mandatory to notify the software providers if any problems or issues are found.

3.6. After staged-rollout, the partner is requested to fill in a report (a report template will be provided in the RT system) and to set the ticket status to βÄ€doneβÄù, this meaning that the task was completed.

3.7. Only after all early adopters have set their status to βÄ€doneβÄù on the ticket, the ticket can be closed by the βÄ€staged-rolloutβÄù group. A summary in writing is produced to summarize the results and possibly provide further comments.

3.7.1. The status report can be: <Success|Warning|Reject>.

3.7.2. The βÄ€WarningβÄù can be set when slight changes to the release notes, to installation or configuration are requested. The staged rollout manager is responsible of this.

3.8. A grace period of up to five working days, is foreseen for the new versions to be βÄ€exposedβÄù to a production environment. This will allow the new version of the service to be used by all the Virtual Organizations that the EA supports for a long enough period for bugs or issues to be exposed.

3.9. Closing the ticket with βÄ€Success|WarningβÄù triggers the transfer of the packages from the βÄ€Staged RolloutβÄù repository to the βÄ€ProductionβÄù one. The broadcast tool of the Operations Portal will then be used to notify all site administrators that a new release is ready for deployment.