Open Stack

Hi,

> So what is open? The composition layer.

We can have different composition layers for every release and it's already
implemented in releases - separate puppet modules/manifests dir for every
release.

> 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.

So we'll have tons of conditionals in composition layer, right? Even if
some puppet-openstack class have just one new parameter in new release,
then we'll have to write a conditional and duplicate class declaration. Or
write complex parameters hash definitions/merges and use
create_resources(). The more releases we want to support the more
complicated composition layer will become. That won't make contribution to
fuel-library easier and even can greatly reduce development speed. Also are
we going to add new features to stable releases using this workflow with
single composition layer?

> 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

I'm sorry, but I don't see how we can accelerate things by making
composition layer more and more complicated. If we're going to run CI and
swarm for all of the supported releases on the ISO, that would rather
decrease speed of development and testing drastically. Also aren't we
"testing both master and keep health on stable" right now by running tests
for master and stable versions of Fuel?

> 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.

Using the same composition layers is not required for this. Also how it
differs from using the current upgrade procedure? When you have, for
instance, 7.0 release and then upgrade to 8.0, so basically result is the
same - you have two releases in Fuel, 2 directories with manifests, 2 repos
with packages.

> 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.

Using the same composition layers is not required for this, "we can keep
the older cases around" in the composition layer of previous version.

Also, how many releases we're going to support? All of them starting from
Kilo? What about ISO size? What about CI, infra (required HW), acceptance
testing, etc impact?

Regards,
Alex



On Thu, Feb 11, 2016 at 6:57 AM, Andrew Woodward <xarses at gmail.com> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/52347133/attachment-0001.html>