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:Feedback from M. David"

From EGIWiki
Jump to navigation Jump to search
Line 52: Line 52:
we will have to figure out if there is need of repo -> RT triggers
we will have to figure out if there is need of repo -> RT triggers


== WorkFlow --
== WorkFlow ==
== Ticket LifeCycle ==


# Software providers
## 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?)


 
# The SW Provider creates a Ticket in GGUS accompanied with all the necessary info:
## The software provider has to provide the following information in the RT ticket, upon ticket creation:
## 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.
### Release notes, or the link to them. The release notes should link to the advisory written by the Software Vulnerability Group (SVG),
## Changelog, or the link to it. This can be already provided either inside the package or be part of the release notes.
in the case of a software vulnerability.
## Certification report(s) (from the agreed quality assurance documentation and tests) or a link.
### Changelog, or the link to it.
## Link to documentation: users manual, system administration manual, etc. The documentation should be updated if applicable, for example if the release introduces new functionality.
''MDavid: I agree with Ales, this piece should be already provided either inside the package or be part of the release notes.''
## 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.
### Certification report(s) (from the agreed quality assurance documentation and tests) or a link.
## 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.
### Link to documentation: users manual, system administration manual, etc. The documentation should be updated if applicable,
# The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“
for example if the release introduces new functionality.
# Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
### Links to all bugs, issues, features in this new release.
# The Repo Processes the ticket
### The ticket is then assigned to the EGI Repository Manager.
## Downloads the software bundle and puts it on the “Unverified” Repository
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
## The Repo parses the attached xml
### 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.
## Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
### The EGI Repository team, assigns the ticket to the EGI Technology Unit group, after step 1.4 is successfully accomplished.
### '''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.
''MDavid: I think that 1.4 and 1.5 have to be merged into:''
### '''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
## The EGI Repository Manager pulls the packages (rpm, deb, tar, etc.) into the EGI repository called βÄ€UnverifiedβÄù, and after automatic
# In both 4.3 cases, the RT Notifies the EGI Technology Unit Group (i.e the Ticket is Assigned to the EGI TUG):
checksum verification they set the "Assigned" field to "Technical-unit", the technical unit is thus notified and one of the persons from this
## Verifies the new version. This includes the verification of all information provided according to point 1.
group set himself as "owner" of the ticket. If this step fails, the process is repeated.
###  If the verification is successful the packages are moved into the "Staged Rollout" repository.
Again that is how the EGI TechUnit knows that there is a sw component to be verified.
### 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.
 
## 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.
# EGI Technology Unit (MU) [R1]:
## 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
## Verifies the new version. This includes the verification of all information provided according to step 1.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.
 
## 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
 
## 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
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.
managers are notified and take over the ticket.'''
 
# 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
# EGI Operations Unit (OU):
# Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
 
# The Repo Processes the ticket
## The βÄ€staged-rolloutβÄù group notifies the corresponding βÄ€early-adoptersβÄù group βÄ™ through a ticket βÄ™ that a new version of a given
## Move the SW to stage-rollout  
middleware component or operational tool is ready for staged-rollout.
## The Repo updates the RT setting the RepoStatus of the ticket to “Stage-Rollout” + the URI where the new software can be found, etc.
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
#   RT Notifies the Staged-Rollout managers
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.
#   If everything it is OK, the Staged-Rollout managers change the RepoAction field to “MoveToProduction”
 
#    Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
## Any early adopter participating staged-rollout of the relevant component should enter the RT and βÄ€acceptβÄù the ticket within one
#   The Repo Processes the ticket  
working day after the notification.
##   Move the SW to production
 
##   The Repo updates the RT setting the RepoStatus of the ticket to “Production” + the URI where the new software can be found, etc.
### 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βÄù.
 
 
### Any other early adopter can also βÄ€acceptβÄù the same ticket.
 
### Any number of early adopters can contribute to staged-rollout for any given component.
 
### 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
 
## 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.
 
 
## 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.
 
## It is mandatory to notify the software providers if any problems or issues are found.
 
## 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.
 
## 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.
 
### The status report can be: <Success|Warning|Reject>.
 
### 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.  


## A grace period of up to five working days, is foreseen for the new versions to be βÄ€exposedβÄù to a production environment.
…. and the life goes on ….
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.


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

Revision as of 18:54, 22 September 2010

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

WorkFlow

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

...

Retrieved from "https://wiki.egi.eu/w/index.php?title=EGI-InSPIRE:Feedback_from_M._David&oldid=3184"