Versions Compared

Old Version 2

changes.mady.by.user Vincenzo Spinoso

Saved on

compared with

New Version 3

changes.mady.by.user Vincenzo Spinoso

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Every CMD major release will stick to a specific OpenStack release or OpenNebula release and handle the respective release cycles. Please have a look at the CMD release schedule for more information.

At the moment all the products in CMD must be available both as CentOS7 and Ubuntu Xenial packages.

...

  • infrastructure readiness: frontend to be adapted, backend+RT are OK
  • Verification: a proposal will be made on how to make it in the CMD context just like we do in UMD, IFCA will provide resources for the OpenStack platform and CESGA for the OpenNebula; wiki to be filled
  • Staged-Rollout process: wiki to be filled
  • Products https://wiki.egi.eu/wiki/EGI_Cloud_Middleware_Distribution_products to be filled
  • XMLs to be created

Release process

StepActionAction onDescriptionTimeline
1SubmissionTechnology Providersubmit a GGUS ticket, assigned to Support Unit "EGI Software provisioning support", providing them with the following information:
  • Product release and version number
  • Link to the release notes
  • Full list of packages that compose the release and that need to be released
at TP convenience
2InjectionUMD Team SR Managerinject the product release in the EGI SW provisioning infrastructure:
  • One or more RT tickets are created to track the progress of the inclusion of the new product release; the status of the product release will then be tracked in RT, the status of the RT ticket just is initially Unverified
  • The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and closes as 'solved' the GGUS ticket
5 working days
3Quality Verification startsUMD Team QC Verifierthe QC verifier starts the verification process, switching the status of the RT ticket from "Unverified" to "Verification"the QC verification must start in one month after the creation of the RT ticket; after a month with the verification not yet started:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
4Quality Verification executionUMD Team QC Verifierthe UMD team is verifying the product in the testbed; after the verification process is completed, the RT ticket status is switched from "Verification" to "Staged Rollout"an RT ticket cannot stay longer than one week in verification; after one week with the verification not yet completed:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
5Staged RolloutUMD Team Staged Rollout managerThe product is announced to the early adopters testing the product in staged rollout.RT tickets cannot stay longer than one month in the "Staged Rollout" status; after a month with the staged rollout not yet completed:
  • the RT ticket will be updated with an explanation for the delay
  • the status will be changed to "Delayed" [*]
  • the Technology Provider will be informed (using the contacts in the product ID card)
6Inclusion in the next releaseRelease managerinclude the product in the next releasesee the CMD release schedule

[*] Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.

...