Open Stack

Hi,

The Octane team has some issues with lacking definition of what the
'release' is in Fuel (in terms of managed environments). I started an
etherpad [1] to summarize the entities/artifacts that consistute a
'release' at the moment. Based on this definition, we can localize and
define entry points where the actual 'release'-specific code could be
separated from universal frameworks in Nailgun and other component of Fuel.
Thus, we could better manage different releases with a single version of
Nailgun code, which is essential for the upgrade workflow.

I agree with Alex on that at least a part of the composition layer is bound
to be 'release'-specific, especially the puppet modules that deploy
OpenStack and other managed components. On the other hand, certain parts of
the fuel-library have nothing to do with the managed 'release', and concern
the Fuel Admin node itself. It would be useful to make separation along
those lines as well.

[1] https://etherpad.openstack.org/p/fuel-release-definition

--
Best regards,
Oleg Gelbukh

On Thu, Feb 11, 2016 at 12:02 PM, 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.
>
> > 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
>>
>>
>
> __________________________________________________________________________
> 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/75b2f488/attachment.html>