CMD (Cloud Middleware Distribution) aims at distributing:

  • OpenStack and OpenNebula integration components (not the framework themselves),
  • products that are more in general deployed on top of OpenStack/OpenNebula
  • other products that enhance the IaaS layer of the federated cloud, even if they’re not directly dependent on OpenStack/OpenNebula

CMD supports OpenStack and OpenNebula, through two different distributions:

  • CMD-OS (OpenStack)
  • CMD-ONE (OpenNebula)

Components are included as follows:

  • OpenStack specific components -> CMD-OS
  • OpenNebula specific components -> CMD-ONE
  • common cloud components (BDII, SSM, VMCatcher...) -> all CMD-*

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.

NOTICE: Regular grid components and in general all non cloud-specific components will keep going to UMD. At the moment UMD4 is supported, accepting CentOS7 and SL6 packages. Ubuntu is not yet enabled. Products in UMD major releases should have a release cycle that is compatible with the UMD one: major releases are supported with updates for at least 1 year, security for 2 years.

Including your products into CMD

In order to include your products in CMD, you need to:

  1. join URT as a Technology Provider
  2. add your products to CMD, providing all the needed related information
  3. start the technical inclusion process, named Software Provisioning Process

Please follow the instructions below to do so.

Join URT as Technology Provider

URT is a coordination group, under the EGI Operations umbrella. The goal of URT is to continue some of the coordination activities carried out by the Europan middleware projects, keep the communications active between product teams and to open a communication channel between the EGI and the middleware developers.

Technology Providers share a common mailing list (urt-discuss) and follow the UMD Release Team meetings.

Please check if you are already a member of the URT giving a look at the Technology Provider page. If so, you can skip to the next section.

In order to join as a Technology Provider, or to add a new product to the release, the Technology Provider needs to:

  • get an EGI SSO if you don't have one
  • send an email to operations at, asking to be added to the URT group; in the email, please include the following details:
    • Name of the Technology provider
    • Products you want to include and to support, with their description
    • Name and contact details of the Team Leader
    • Other contacts (support email address, web site address, representative at the URT meeting)

Add your products to CMD

For each product to be included in CMD, the Technology Provider is asked to:

  • provide a complete Product ID Card description, which will be used to contact the Technology Provider in case of requests for information, security related events/issues, proposals, and any other issues
  • create GGUS Support Unit to receive and handle incidents
  • agree on Technical Provider Underpinning Agreement (TP UA) with, for a single product or for a group of products

For each of the steps above, please ask for help to operations at

Software Provisioning Process

After performing the steps above, your product can be added to CMD releases following the middleware distribution process.


If you need information or details on CMD, please write to operations at

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.


For further details on the Verification Process, please visit EGI Quality Assurance


For further details about the Staged-Rollout process, please visit Staged Rollout

Release process


  • No labels