Open Stack

On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <adidenko at mirantis.com>
wrote:

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

This requires the loss of all of the features in the newer version of fuel
since it relies on the older version of the serialized data from nailgun.
In addtion we currently don't allow for new clusters to be deployed this
way.


>
> > 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?
>
> Yes, we need conditionals in the composition layer, we already need these
to no jam the gate when we switch between stable and master, we might as
well maintain them properly so that we can start running multiple versions

Yes, this is, in part,  about taking advantage of new fuel features on
stable openstack releases, we are almost always behind and the previous
release(s) supported this already.

If its only supported in the newer version, then we would have a similar
problem with enabling the feature anyways as our current process results in
us developing on stable openstack with the newer fuel until late in the
cycle, when we switch packaging over.

>
> > 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?
>
> No, this is about deploying stable and master from the same version of
Fuel, with the new features from fuel. As we develop new features in fuel
we frequently run into problems simply because openstack version we are
deploying is broken, this would allow for gating on stable and edge testing
master until it can become the new stable.

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

Again, we lose compatibility with the data from nailgun by simply pulling
in the old composition layer, we loose all new features that the
composition layer exposes

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

On average, two openstack releases would be supported the version that this
fuel is being developed for, and the prior stable openstack release. There
is an abnormal exception for Kilo. For 9 I would propose Kilo and Mitaka if
we want to keep it to just two.

ISO size, only one release should be bundled on the ISO, the other can
exist on the external package repos. the default release should be included
by default We would want to add parameter to pick this for during build if
someone wanted the other version

For the normal workflow (as an extension of how we function currently
anyway). We would gate the fuel cycle on the stable release and have a
non-voting basic test on master version. We would run regular BVT on both.
When we are ready to switch to the master release because of RC
availability or other high stability, then we would flip this. Stable would
become basic non-voting test and "master" (at this point new stable) would
get the gate


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

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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