EGI-InSPIRE:NSRW IMPLEMENTATION RT
General Comments / Assumptions
- External Technology Providers will use GGUS to submit tickets
- Internal Technolgy Providers will use RT to submit tickets
- Emergency Releases (External and Internal) will be handled only by RT
- This is Based on Feedback_from_M._Drescher
(Custom) fields
EmergencyRelease
This is a check-box field used to flag a release as an emergency one which implies that the release should go straight to production
Status
Existing field. Takes the general RT status of the ticket.
Allowed values:
- new - Ticket is created, but not assigned yet. Initial state once synched from GGUS.
- open - Ticket is assigned to a person or group (does that feature exist in RT?) and work is undertaken
- rejected - The ticket is faulty, invalid, duplicate or otherwise something that must not inflict work upon potential assignees.
- resolved - The request has been resolved with an outcome (and auditable trace of documentation etc.!). Causes the ticket to be synchronized back to GGUS.
- deleted - does not apply
- stalled - does not apply(?)
RolloutProgress
The RolloutProgress reflects both the phases of the SW release workflow, and the final outcome.
Allowed values:
- Submitted - This is the initial value of the ticket till the new release is downloaded in the "Unverified" Repo to be checked.
- Unverified - The pertinent release has not yet been verified against the Quality Criteria (QC), but is available for that in the "Unverified" repository.
- In verification - The release is under assessment against the QC.
- Waiting for response - The QC verification officer is waiting for a response from the technology provider for one or more minor, uncritical issues of the package (missing documentation link, for example). Note that the state may oscillate between "In verification" and "Waiting for response". Each state change is recorded hence available for metrics.
- StageRollout - The release has been successfully verified, and a link to the final verification report in the document database has been provided in the ticket.
- Accepted - The EA have tested the release in their production infrastructure (open issue what is the testing process? Is this anywhere formalised?), and written reports of each EA were aggregated and consolidated by the assigned release manager. The consolidated report is stored in the document database with references to the individual EA reports. A link to the aggregated report is given in the ticket. The aggregated report also MUST report any warnings issued by any EA during the StageRollout phase of the release.
- Rejected - The EA have tested the release in their production infrastructure. Same reporting requirements as for "Accepted" apply. A release may also fail the QC verification. In that case the report must be present reasoning about the failure of the verification.
- Failed - Verifying the release has failed, due to technical issues, such as repository unavailability, network timeouts, etc. The detailed reason is given in the message when changing the ticket status. This most likely happens when moving the release from one repository to another, e.g. from "Unverified" to "StageRollout".
QualityCriteria Verification Report
This field holds a link to the report of the QC verification process.
StageRollout Report
This field holds a link to the consolidated report summarising individual reports of all EAs.
Repository URL
Holds the currently valid URL to download the installation package. So, if the ticket has the current RolloutProgress of "StageRollout" (or equivalent), the URL should point to the package in the StageRollout repository.
Release metadata
This "field" I envision not really a field, but an attachment to the ticket that holds the XML data for the release referred to in this ticket. Didn't know how to describe it. For better automation the attachment should always have the same name (for example, "release.xml") and be attached throught the WS integration with GGUS (if possible).
The contents of this XML file is currently under discussion, so I will not drill into it right now.
Owner
The owner of the ticket should change from person to person, depending on the progress through the workflow. I am not a fan of assigning the ticket to a group of people, as this often leads to confusion as to who should pick up the ticket. For now I would like to see group leaders, such as the Task leaders for QC verification (TSA2.3, Carlos Fernandez), and the Task Leader for SR (TSA1.x, Mario David) as standing assignees who then delegate the work appropriately, and collect and consolidate the reports (see other custom fields, and workflow comments).
Watchers
I would like a list of watchers added to the tickets to ensure proper monitoring. Again, I think the task leaders for QC verification and SR are mandatory watchers, as well as the task leader for repository management (TSA2.4, Kostas). I also would want the members of said tasks (TSA2.4 and TSA2.3 in particular) as watchers. The activity leader for SA2 (currently me, Michel) should be a mandatory watcher as well.
I am thinking of the task leader of TSA2.5, Michael, to also watch this queue as to give the DMSU a forecast on what is in the current pipeline of patches that may be rolled out into production.
I also would like to include the group of early adopters in SR to be watchers, to get their heads up for what's going on. But that needs more discussion that perhaps Mario David may lead.
Associated Major Release OR Associated Software
Provides the association of the given release, with a higher level "object" (i.e. "Major release" or even a "Software"). This object should be characterized by a set of static/agreed attributes.
For example, the location on the production repository, where each release associated with an "object" should be populated.
One more (more pragmatic) example: Since the release ca-policy-egi-core-1.37-1 it is associated with the ca-1.0 major release, then the ca-policy-egi-core-1.37-1 should be populated at http://repository.egi.eu/sw/production/CAs/.
[From my point of view, these (they are more than one) kind of attributes, should be decided within the EGI and agreed (maybe) with the provider. They should be at a major release level (or at least at a software level) and they should be updated, for example on a major release sequence]
Workflow
The workflow itself seem look fine. We have three distinct phases, i.e.
- Preparation
- Verification
- StageRollout
We have enough details available to flesh out all three phases, but I am still a bit unclear about the handover between all three phases. I consider those handovers very important as the responsibility for the ticket changes from one task/group to another.
Having said that, I would like to explicitly state that the group leader for the Verification Phase has the authority to change the RolloutProgress from "Unverified" to "Rejected", "Waiting for Reply" or "StageRollout". Likewise, the group leader for the StageRollout has the authority to change the ticket status from "StageRollout" to "Accepted" or "Rejected". The status of the ticket may also be changd accordingly (e.g. to "Resolved").
To →
From↓| |
Unverified|In verification|Waiting for response|StageRollout|Accepted|Rejected|Location in repository
Submit||||||Emerg. Rel.||- Unverified||||||||unverified In verification||||||||unverified Waiting for response||||||||unverified StageRollout||||||||stagerollout Accepted||||||||production Rejected||||||||'rejected (??)' |
Requests/Issues
Issues | Description | Requester | Status |
---|---|---|---|
Bla | Bla | Bla | Bla |
Fields in RT Ticket
Field | Description | Values | Read | Write | Status |
---|---|---|---|---|---|
RepositoryURL | Holds a Pointer to the Release in EGI Repo. | All | Repo | Implemented | |
Sync-Protocol | indicates which protocol to be used to download the data | rsync (later http, ftp will be added)
default: rsync null: no |
All | SW-Provider | Implemented |
Sync-URL | Points to the repo from which we download the release to our reposiotory | null: no | All | SW-Provider | Implemented |
Associated Major Release
or Associated Software |
See above | See above
null: no |
All | SW-Provider | pending |
ReleaseType | Indicates whether the given release, should be handled by the Repo as NonIncremental or as an Incremental one. | NonIncremental Incremental
default: NonIncremental null: no |
All | SW-Provider | Implemented |
EmergencyRelease | See Above | No, Yes
default: No null: no |
All | SW-Provider | Implemented |
Status | See Above | See Above
default: new null: no |
All | Verification teams | Implemented |
RolloutProgress | See Above | See Above
default: Submitted null: no |
All | Verification teams,
Repo (in case of a failure) |
Implemented |
Verification-Report | See Above | See Above
null: no |
All | Verification teams | Implemented |
StageRollout-Report | See Above | See Above
null: no |
All | Stage-Rollout Verification team | Implemented |
Release-metadata | See Above | See Above
null: no |
All | SW-Provider | Implemented |
Owner | See Above | See Above
null: no |
All | - (??) | Implemented |
Watchers | See Above | See Above
null: no |
All | - (??) | Implemented |
Legend
- Proposed: Field proposed by the developers awaiting implementation
- Pending: Approuved by SA2 Awaiting Implementation
- Implemented: Field already implemented in RT
Metrics for the REPO
Metrics from SLA with TPs
Metric | Description | Status |
---|---|---|
M.REPO.1 | Number of releases delivered to EGI Per month | Pending |
M.REPO.2 | Number of releases that passed the quality criteria verification Per Month. | Pending |
M.REPO.3 | Number of releases that passed StageRollout verification Per month. | Pending |
Legend
- Proposed: Field proposed by the developers awaiting implementation
- Pending: Approuved by SA2 Awaiting Implementation
- Implemented: Field already implemented in RT
Metrics for the REPO
Metrics from SLA with TPs
Metric | Description | Status |
---|---|---|
M.REPO.1 | Number of releases delivered to EGI Per month | Pending |
M.REPO.2 | Number of releases that passed the quality criteria verification Per Month. | Pending |
M.REPO.3 | Number of releases that passed StageRollout verification Per month. | Pending |
EGI SA2 Metrics
Metric ID | Metric | Task | Status |
---|---|---|---|
M.SA2.1 | Number of software components recorded in the UMD Roadmap | TSA2.1 | Pending |
M.SA2.2 | Number of UMD Roadmap Capabilities defined through validation criteria | TSA2.2 | Pending |
M.SA2.3 | Number of software incidents found in production that result in changes to quality criteria | TSA2.2 | Pending |
M.SA2.4 | Number of new releases validated against defined criteria | TSA2.3 | Pending |
M.SA2.5 | Mean time taken to validate a release | TSA2.3 | Pending |
M.SA2.6 | Number of releases failing validation | TSA2.3 | Pending |
M.SA2.7 | Number of new releases contributed into the Software Repository from all types of software providers | TSA2.4 | Pending |
M.SA2.8 | Number of unique visitors to the Software Repository | TSA2.4 | Pending |
M.SA2.9 | Number of releases downloaded from the Software Repository | TSA2.4 | Pending |
M.SA2.10 | Number of tickets assigned to DMSU | TSA2.5 | Pending |
M.SA2.11 | Mean time to resolve DMSU tickets | TSA2.5 | Pending |