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
 
(51 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{EGI-Inspire_menubar}}
{{TOC_right}}
== Ticket LifeCycle ==
== Ticket LifeCycle ==


# The SW Provider Creates a Ticket in GGUS accompanied with all the neccesary info  
 
# The ticket is Transfered from GGUS to RT, Status of the Ticket is New
# The SW Provider creates a Ticket in GGUS accompanied with all the necessary info  
# RT Notifies the Repo there is a new ticket to be processed, Status of the Ticket remains new  (i.e the Ticket is Assigned to  the REPO)
# The ticket is transferred from GGUS to RT, the RepoAction field of the ticket is “MoveToUnverified“
# The Repo Processes the ticket
# Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
## The Repo Downloads the software bundle and puts it on the Unverified Repository  
# The Repo Processes the ticket  
## Downloads the software bundle and puts it on the “Unverified” Repository
## The Repo parses the attached xml  
## The Repo parses the attached xml  
## The Repo updates RT with the info extacted from the xml + the Uri where the new software can be found  
## Based on the metadata contained at both, the ticket itself and the attached xml, the Repo performs the necessary actions
##  The Status of the ticket is set to Unverified
### '''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.
# RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)
### '''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 info related to the failure
# EGI TUG -- please fill in the intermedate steps here
# In both 4.3 cases, the RT Notifies the EGI Technology Unit group (i.e the Ticket is Assigned to the EGI TUG)  
#   Depending on the outcome
## '''EGI TUG -- The ticket is assigned a verifier'''
## if Success the Ticket is Marked MoveToStageRollOut
## '''EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .'''
...
## '''EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification'''
## '''EGI TUG -- If the verification is not OK, and minor issues are found, the SP is notified and has 1-2 days (depending on the type of release) to solve or clarify the issues. The ticket is moved to Verified-issues'''
## '''EGI TUG -- If the verification is not OK, and has major issues or the grace-period has passed without correcting the issues, the ticket is moved to Rejected and the SP get a notification'''
# 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  
# Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
# The Repo Processes the ticket
## Move the SW to stage-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.
#    RT Notifies the EA and/or '''MarioD''' or whoever is responsible to handle the stage-rollout process ('''MarioD?? any suggestion on this?''')
#    If everything it is OK, MarioD change the RepoAction field to “MoveToProduction”
#    Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
#    The Repo Processes the ticket
##    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.


…. and the life goes on ….


[[File:EGI-SW-Release-Workflow.png‎ ]]
...


== Work Flow ==
== Required Fields ==


'''RepoAction :''' Actions to Be Performed by the Repo, Values MoveToUnverified,MoveToStageRollOut,MoveToProduction,Reject,Depreceate


== MetaDATA ==
'''RepoStatus :''' Response to RepoActions, Values Uverified,StateRollOut,Production,Depreceated,Failed


[[NRMS New Release MetaDATA schema]]
== Work Flow ==


== Ticket Status Values ==


== Related Info ==
== Proposed Structure for the Repository ==
[[http://repository.egi.eu/sw/ Protoytpe Repo]]


=== Feedback from M. David ===
'''stagerollout'''
<pre>
/sw/stagerollout/CAs/egi/
/sw/stagerollout/CAs/lcg/
/sw/stagerollout/umd/1.0/…..
/sw/stagerollout/globus/x/x.y/…..
/sw/stagerollout/jra1/nagios/
/sw/stagerollout/jra1-sw1
/sw/stagerollout/jra1-sw2
/sw/stagerollout/……….
</pre>


Workflow staged-rollout
'''Production'''


This is slighlty altered version which is in MS402 V6 after S. Newhouse comments/review
<pre>
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
/sw/production/CAs/egi/
staged-rollout queue and custom scrips triggering actions on changes of the ticket
/sw/production/CAs/lcg/
status or custom fields status.
/sw/production/umd/1.0/…..
MDavid: OK, Correct
/sw/production/globus/x/x.y/…..
/sw/production/jra1/nagios/
/sw/production/jra1/jra1-sw1/
/sw/production/jra1/jra1-sw2/
/sw/production/……….


Custom fields
</pre>
"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)
== MetaData ==
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)
[[NRMS New Release MetaDATA schema]]
- 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)
== Ticket Status Values ==
- 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
== Questions/Issues ==
"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
Insert any question / issue you may have here to keep track of them
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


* '''Define Scope of a Release (e.g. delta to a respective base Bundle or not ?)'''
* '''Define / Finalize the Relese Metadata Schema.'''


[[EGI REPO Team Issues]]


1. Software providers
== Related Info ==


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
[[File:EGI-SW-Release-Workflow.png‎ ]]
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
[[Feedback from M. David]]
comments during the staged-rollout process.
MDavid: I will change this to, the "Status" is already βÄ€rolling-outβÄù.


[[Feedback from M. Drescher]]


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


3.2.3. Any number of early adopters can contribute to staged-rollout for any given component.
Current Quality Criteria: [[EGI-InSPIRE:UMDQualityCriteria]]


3.2.4. From this point forward, only the early adopter teams that accepted the staged-rollout for a given component, will
The current template for Quality Criteria verification can be found [https://documents.egi.eu/secure/ShowDocument?docid=208 here].
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?
[https://documents.egi.eu/secure/ShowDocument?docid=46 MS501]
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
[https://documents.egi.eu/secure/ShowDocument?docid=68 MS503]
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.


[https://documents.egi.eu/secure/ShowDocument?docid=89 MS504]


3.4. A given early adopter should primarily βÄ€acceptβÄù staged-rollout for the components it has officially committed to. However,
[https://documents.egi.eu/secure/ShowDocument?docid=100 UMD RoadMap]
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.
[https://documents.egi.eu/secure/ShowDocument?docid=53 MS402]


3.6. After staged-rollout, the partner is requested to fill in a report (a report template will be provided in the RT system)
[[NGI_CZ:RT_GGUS_Integration]]
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.
[[NSRW_IMPLEMENTATION_RT]]
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>.
[[Quality_Assurance:Main_Page]]


3.7.2. The βÄ€WarningβÄù can be set when slight changes to the release notes, to installation or configuration are requested.
[https://documents.egi.eu/secure/ShowDocument?docid=55 Metrics]
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.
[[Internal TPs Process for a new software release]]
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
--[[User:Kkoum|Kkoum]] 07:17, 28 September 2010 (UTC)
βÄ€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.

Latest revision as of 23:19, 24 December 2014

EGI Inspire Main page



Ticket LifeCycle

  1. The SW Provider creates a Ticket in GGUS accompanied with all the necessary info
  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 info 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. EGI TUG -- The ticket is assigned a verifier
    2. EGI TUG -- The verifier checks the information available and fills the GQC template and the SQC template for the component .
    3. EGI TUG -- If the verification is OK, the ticket is moved to Stage-rollout (see step 6) and the SP get a notification
    4. EGI TUG -- If the verification is not OK, and minor issues are found, the SP is notified and has 1-2 days (depending on the type of release) to solve or clarify the issues. The ticket is moved to Verified-issues
    5. EGI TUG -- If the verification is not OK, and has major issues or the grace-period has passed without correcting the issues, the ticket is moved to Rejected and the SP get a notification
  6. 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
  7. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
  8. 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.
  9. RT Notifies the EA and/or MarioD or whoever is responsible to handle the stage-rollout process (MarioD?? any suggestion on this?)
  10. If everything it is OK, MarioD change the RepoAction field to “MoveToProduction”
  11. Upon RepoAction field change, the RT Notifies the Repo that there is a ticket to be processed
  12. 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 ….

...

Required Fields

RepoAction : Actions to Be Performed by the Repo, Values MoveToUnverified,MoveToStageRollOut,MoveToProduction,Reject,Depreceate

RepoStatus : Response to RepoActions, Values Uverified,StateRollOut,Production,Depreceated,Failed

Work Flow

Proposed Structure for the Repository

[Protoytpe Repo]

stagerollout 

/sw/stagerollout/CAs/egi/
/sw/stagerollout/CAs/lcg/
/sw/stagerollout/umd/1.0/…..
/sw/stagerollout/globus/x/x.y/…..
/sw/stagerollout/jra1/nagios/
/sw/stagerollout/jra1-sw1
/sw/stagerollout/jra1-sw2
/sw/stagerollout/……….

Production 


/sw/production/CAs/egi/
/sw/production/CAs/lcg/
/sw/production/umd/1.0/…..
/sw/production/globus/x/x.y/…..
/sw/production/jra1/nagios/
/sw/production/jra1/jra1-sw1/
/sw/production/jra1/jra1-sw2/
/sw/production/……….

MetaData

NRMS New Release MetaDATA schema

Ticket Status Values

Questions/Issues

Insert any question / issue you may have here to keep track of them

  • Define Scope of a Release (e.g. delta to a respective base Bundle or not ?)
  • Define / Finalize the Relese Metadata Schema.

EGI REPO Team Issues

Related Info

EGI-SW-Release-Workflow.png

Feedback from M. David

Feedback from M. Drescher

NSRW_feedback_Milos_and_Ales

Current Quality Criteria: EGI-InSPIRE:UMDQualityCriteria

The current template for Quality Criteria verification can be found here.

MS501

MS503

MS504

UMD RoadMap

MS402

NGI_CZ:RT_GGUS_Integration

NSRW_IMPLEMENTATION_RT

Quality_Assurance:Main_Page

Metrics

Internal TPs Process for a new software release

--Kkoum 07:17, 28 September 2010 (UTC)

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