Difference between revisions of "EGI Cloud Middleware Distribution"
Jump to navigation
Jump to search
Line 3: | Line 3: | ||
A new distribution, called Cloud Middleware Distribution (CMD), will be created: | A new distribution, called Cloud Middleware Distribution (CMD), will be created: | ||
* CMD is just a new distribution, like UMD, starting from major release number 1, going in parallel with UMD (used for separated grid stuff with bigger release cycles) | * CMD is just a new distribution, like UMD, starting from major release number 1, going in parallel with UMD (used for separated grid stuff with bigger release cycles) | ||
* 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 | * 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 | ||
* every CMD major release will stick to a specific OpenStack release, for instance: | * CMD will follow the OpenStack release cycle (6 months) and the OpenNebula major release cycle (years); | ||
* every CMD major release will stick to a specific OpenStack release or (exclusive) OpenNebula release, for instance: | |||
** CMD1 | ** CMD1 Liberty | ||
** CMD2 | ** CMD2 one5 | ||
** CMD3 | ** (CMD3) (Mitaka) | ||
* | * in both OpenStack/OpenNebula contexts, the framework release does not really matter to CMD; the OS supported does (for path naming etc) | ||
* CMD1 will support '''CentOS7 and Ubuntu 14.04 LTS''' | * CMD1 (Liberty) and CMD2 (one5) will support '''CentOS7 and Ubuntu 14.04 LTS''' | ||
* '''all the products must be available both as CentOS7 and Ubuntu packages''' | * in fact '''all the products must be available both as CentOS7 and Ubuntu packages''' | ||
* only integration components will be included in CMD, not the OpenStack/OpenNebula | * only integration components will be included in CMD, not the OpenStack/OpenNebula themselves | ||
* no changes have been requested to the regular UMD workflow, so verifications, SR etc will be allowed and performed as well with no deveopment needed on the repository side | * no changes have been requested to the regular UMD workflow, so verifications, SR etc will be allowed and performed as well with no deveopment needed on the repository side | ||
* two or more versions of CMD will be distributed in parallel, following the need of sites to stick with their installations | * two or more versions of CMD will be distributed in parallel, following the need of sites to stick with their installations | ||
* after creating the first | * after creating the first CMD release we will use the experience to create a procedure to create the next version of CMD to make it straightforward every 6 months |
Revision as of 13:55, 24 March 2016
Cloud Middleware Distribution
A new distribution, called Cloud Middleware Distribution (CMD), will be created:
- CMD is just a new distribution, like UMD, starting from major release number 1, going in parallel with UMD (used for separated grid stuff with bigger release cycles)
- 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
- CMD will follow the OpenStack release cycle (6 months) and the OpenNebula major release cycle (years);
- every CMD major release will stick to a specific OpenStack release or (exclusive) OpenNebula release, for instance:
- CMD1 Liberty
- CMD2 one5
- (CMD3) (Mitaka)
- in both OpenStack/OpenNebula contexts, the framework release does not really matter to CMD; the OS supported does (for path naming etc)
- CMD1 (Liberty) and CMD2 (one5) will support CentOS7 and Ubuntu 14.04 LTS
- in fact all the products must be available both as CentOS7 and Ubuntu packages
- only integration components will be included in CMD, not the OpenStack/OpenNebula themselves
- no changes have been requested to the regular UMD workflow, so verifications, SR etc will be allowed and performed as well with no deveopment needed on the repository side
- two or more versions of CMD will be distributed in parallel, following the need of sites to stick with their installations
- after creating the first CMD release we will use the experience to create a procedure to create the next version of CMD to make it straightforward every 6 months