Open Stack

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

Yes. But isn't it how "stable" branches are supposed to work? Introducing
new features into "stable" branches will make them not so "stable", right?
Even if these new features are introduced in composition layer or
configuration data. just an example: network transformations in astute.yaml
that are being translated into actual network configuration.

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

Introducing new features to stable releases will require full cycle of
testing. So, basically, it will affect the whole development process.

> In addtion we currently don't allow for new clusters to be deployed this
way.

We can remove this restriction. Nailgun is able to serialize data for
previous releases because that's how it supports adding new nodes to older
environments after upgrade, so it should not be a problem.

Regards,
Alex

On Fri, Feb 12, 2016 at 10:19 PM, Andrew Woodward <xarses at gmail.com> wrote:

>
>
> 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
>
> __________________________________________________________________________
> 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/20160217/e1cf50cf/attachment.html>