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 Cloud Middleware Distribution"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{CMD_Menu}} {{TOC_right}}
{{CMD_Menu}} {{TOC_right}}


== Cloud Middleware Distribution ==
== Cloud Middleware Distribution (CMD) ==


One or more new distributions, called Cloud Middleware Distributions (CMD), will be created and managed. No changes are needed to create a new distribution; composer has been built to support several distributions, but never used so it has just to be tested. Each distribution, just like UMD, will start from major release number 1, going in parallel with UMD (already used for separated grid products).  
CMD goal is distributing OpenStack and OpenNebula integration components (not the framework themselves).  


The new cloud distributions will be used to distribute OpenStack and OpenNebula integration components (not the framework themselves). '''All the products must be available both as CentOS7 and Ubuntu packages'''. Two or more versions of the same CMD distribution will be distributed in parallel, following the need of sites to stick with their installations.
No changes have been requested to the regular UMD workflow, so verifications, SR, etc. will be allowed and performed as well on the cloud distributions with no development needed on the repository side. No changes are needed to create a new distribution; composer has been built to support several distributions, but never used so it has just to be tested. Each distribution, just like UMD, will start from major release number 1, going in parallel with UMD (already used for separated grid products).  
 
No changes have been requested to the regular UMD workflow, so verifications, SR, etc. will be allowed and performed as well on the cloud distributions with no development needed on the repository side.  


After creating the first CMD release we will use the experience to create a straightforward procedure to create the next major/minor versions.  
After creating the first CMD release we will use the experience to create a straightforward procedure to create the next major/minor versions.  


At the moment, two platforms will be supported:  
Two platforms will be supported:  


* OpenStack
* OpenStack
Line 18: Line 16:
As a consequence, two distributions will be created:  
As a consequence, two distributions will be created:  


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


Components will be included as follows:  
Components will be included as follows:  
Line 30: Line 28:
[[File:two-distros.png|800px|center]]
[[File:two-distros.png|800px|center]]


The two CMD distributions, one for OpenStack (CMD-OS) and one for OpenNebula (CMD-ONE), will handle the respective release cycles (6-months and years). Every CMD major release will stick to a specific OpenStack release or OpenNebula release, for instance
The two CMD distributions, one for OpenStack (CMD-OS) and one for OpenNebula (CMD-ONE), will handle the respective release cycles (6-months and years). Every CMD major release will stick to a specific OpenStack release or OpenNebula release, for instance:


**CMD-OS 1 (Liberty)  
**CMD-OS 1 (Liberty)  
Line 36: Line 34:
**CMD-OS 2 (Mitaka)  
**CMD-OS 2 (Mitaka)  
**...
**...
So for OpenStack for instance, two or more major versions of the same CMD distribution will be distributed in parallel, following the need of sites to stick with their installations. Decommissioning will respectively follow OpenStack and OpenNebula as well.
'''All the products must be available both as CentOS7 and Ubuntu packages'''.


Comments:  
Comments:  

Revision as of 15:24, 30 May 2016

CMD menu: Overview Products Process Release schedule


Cloud Middleware Distribution (CMD)

CMD goal is distributing OpenStack and OpenNebula integration components (not the framework themselves).

No changes have been requested to the regular UMD workflow, so verifications, SR, etc. will be allowed and performed as well on the cloud distributions with no development needed on the repository side. No changes are needed to create a new distribution; composer has been built to support several distributions, but never used so it has just to be tested. Each distribution, just like UMD, will start from major release number 1, going in parallel with UMD (already used for separated grid products).

After creating the first CMD release we will use the experience to create a straightforward procedure to create the next major/minor versions.

Two platforms will be supported:

  • OpenStack
  • OpenNebula

As a consequence, two distributions will be created:

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

Components will be included as follows:

  • OpenStack specific components -> CMD-OS
  • OpenNebula specific components -> CMD-ONE
  • common cloud components (BDII, SSM, VMCatcher...) -> all CMD-*
  • regular grid components (in current UMD3/UMD4) -> usual UMD
Two-distros.png

The two CMD distributions, one for OpenStack (CMD-OS) and one for OpenNebula (CMD-ONE), will handle the respective release cycles (6-months and years). Every CMD major release will stick to a specific OpenStack release or OpenNebula release, for instance:

    • CMD-OS 1 (Liberty)
    • CMD-ONE 1 (ONE5)
    • CMD-OS 2 (Mitaka)
    • ...

So for OpenStack for instance, two or more major versions of the same CMD distribution will be distributed in parallel, following the need of sites to stick with their installations. Decommissioning will respectively follow OpenStack and OpenNebula as well.

All the products must be available both as CentOS7 and Ubuntu packages.

Comments:

  • + components follow the natural release cycle of the CMF
  • + easy for the site, one repo and ready to go
  • + coherency in dependencies is guaranteed because all the packages are put together
  • + easier and less error-prone for the release manager
  • + if at some point a common package is not common anymore and used only by one fo the two frameworks, or frequent updates are related only to one of the two frameworks, updates are made only on the specific distribution
  • - common packages are duplicated into each CMF-related distribution