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

From EGIWiki
Revision as of 10:25, 31 March 2016 by Spinoso (talk | contribs)
Jump to navigation Jump to search

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; common components like BDII, Apel, vmcatcher will be pushed into each CMD in production
  • 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

Reasons to have a separated CMD for OpenNebula

  • ONE support would need to migrate their packages to the new CMD every 6 months without real need but the fact that OS is migrating to a new major
  • also decommissioning can bring issues