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.

EGI Cloud Middleware Distribution process

From EGIWiki
Jump to navigation Jump to search
CMD menu: Overview Products Process Release schedule


Description of the process

Step Action on Action
1 Technology Provider submits 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
2 UMD Team injects the product release in the EGI SW provisioning infrastructure:
  • One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release
  • The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket
  • The status of the product release will be tracked in RT
  • This action must be closed in 5 workiong days by the UMD team
  1. The product release is injected in the EGI SW provisioning infrastructure
    • One or more RT tickets are created to track the progresses of the UMD software provisioning of the new product release
    • The UMD Staged rollout manager answers to the GGUS ticket with the link to the RT and close as 'solved' the GGUS ticket
    • The status of the product release will be tracked in RT
    • This action must be closed in 5 workiong days by the UMD team
  2. The RT ticket is in "Unverified" status
    • This is the "waiting line" for the verification process
    • RT cannot stay longer than one month in the "Unverified" status
    • After a month if the verification has not started the RT ticket will be updated with an explanation for the delay and the status will be changed to "Delayed"
    • Product team (using the contact in the Product ID card) will be informed of the delay, with the reasons that caused the delay
    • Being in the "Delayed" status RT tickets can be identified as problematic by the UMD team and followed up more closely.
  3. The RT ticket is in "Verification" status
    • This means that the UMD team is verifying the product in the testbed.
    • An RT ticket cannot stay longer than one week in verification
    • After one week, if it has not been verified it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
  4. Product is in "Staged Rollout" Status
    • The product is announced to the early adopters testing in staged rollout the product.
    • #* RT cannot stay longer than one month in the "Staged Rollout" status
    • After one month, if it has not been tested in staged rollout it is moved to "Delayed" status, with an explanation of the reasons of the delay. PT to be informed as well.
  5. After the staged rollout product is ready to be included in the next UMD release

Verification

Staged-Rollout