Open Stack

Right now master (targeting 9.0) is still deploying liberty and there is
active work going on to support both Kilo and Mitaka. On the review queue
are changes that would make fuel-library in-compatible with the prior
(liberty) openstack release. However I think if we extend a little bit of
effort we can keep some semblance of "support" while creating a pattern for
the Kilo support to continue to use. At the same time this pattern can help
us test parallel versions as we move through openstack releases and should
reduce occurrences of our CI freeze/merge parties

What is this magic pattern? Well its already present, and all be it not
designed for this I think we could quickly make it work. We use the release
fixture already present in fuel. Originally designed to work for upgrades,
we could reuse this within the same fuel release to control various aspects
needed to deploy a separate openstack version.

What we need to support multiple OpenStack versions:
1) Packge repo's that contain the relevant bits. CHECK, this can be toggled
with a new release  [1][2]
2) can point to different Puppet modules CHECK, also in toggled release  [3]
3) Composition layer that supports calls to different puppet-openstack
modules, WIP, it still needs work, but can be done [4]

So what is open? The composition layer.

Currently, we just abandon support for previous versions in the composition
layer and leave them to only be monuments in the stable/<release> series
branches for maintenance. If we instead started making changes (forwards or
backwards that) change the calls based on the openstack version [5] then we
would be able to change the calls based on then needs of that release, and
the puppet-openstack modules we are working with.

Given that we most of the time we would be supporting the previous release
(liberty) (which we should avoid dropping until after dev releases) and the
currently under development release (Mitaka), this will give us some
magical powers.

Testing master while keeping stable. Given the ability to conditional what
source of openstack bits, which versions of manifests we can start testing
both master and keep health on stable. This would help accelerate both fuel
development and deploying and testing development versions of openstack

Deploying stable and upgrading later. Again given the ability to deploy
multiple OpenStack versions within the same Fuel version, teams focused on
upgrades can take advantage of the latest enhancements in fuel to work the
upgrade process more easily, as an added benefit this would eventually lead
to better support for end user upgrades too.

Deploying older versions, in the odd case that we need to take advantage of
older OpenStack releases like in the case of Kilo with a newer version of
Fuel we can easily maintain that version too as we can keep the older cases
around in the composition layer with out adding much burden on the other
components.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957
[2]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906

[3]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371

[4] https://github.com/xarses/fuel-library/tree/9-Kilo

[5]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948

-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/256e9908/attachment.html>