Open Stack

> Given the requirements to be able to use new features in fuel, with an
older version of OpenStack, what alternative would you propose?

For example, it's possible to use existing "release" functionality in Fuel
(release contains granular tasks configuration, puppet modules and
manifests, configuration data). So after upgrade from 8.0 to 9.0 it will
look like this [0] - with separate composition layer for every supported
"release".

> We should allow a user to specify that they want a build a cloud using X
fuel release to deploy Y os with Z OpenStack release.

[0] should work for this as well. But the number of X-Y-Z combinations will
be limited. Well, it will be limited in any case, I don't think that it's
possible to support unlimited number of OpenStack versions in a single Fuel
release.

In case we want to use single composition layer for more than one openstack
version, we need to resolve the following blockers:
- Move everything except composition layer (top-scope manifests and other
granular tasks) from fuel-library to their own repos. Otherwise we'll have
OpenStack version conditionals in modules manifets, providers and functions
which would be a mess.
- Refactor tasks upload/serialization in Nailgun
- (?) Refactor configuration data serialization in Nailgun

And still we'll have to add conditionals to puppet functions that relay on
configuration data directly (like generate_network_config.rb). Or write
some sort of data serialization in front of them in manifests. Or leave
nailgun serialization based on installed version (which is almost the same
as using separate composition layers [0]).

In either case (separate releases or single composition layer) it will
double CI load and testing efforts, because we need to CI/test new features
and patches for 9.0+mitaka and 9.0+liberty.

Regards,
Alex

[0] http://paste.openstack.org/show/487383/


On Thu, Feb 18, 2016 at 9:31 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
wrote:

> On 17.02.2016 18:23, Bogdan Dobrelya wrote:
> >> 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?
> >
> > As I can see from an example composition [0], such code would be an
> > unmaintainable burden for development and QA process. Next imagine a
> > case for incompatible *providers* like network transformations - shall
> > we put multiple if/case to the ruby providers as well?..
> >
> > That is not a way to go for a composition, sorry. While the idea may be
> > doable, I agree, but perhaps another way.
> >
> > (tl;dr)
> > By the way, this reminded me "The wrong abstraction" [1] article and
> > discussion. I agree with the author and believe one should not group
> > code (here it is versioned puppet modules & compositions) in a way which
> > introduces abstractions (here a super-composition) with multiple
> > if/else/case and hardcoded things to switch the execution flow based on
> > version of things. Just keep code as is - partially duplicated by
> > different releases in separate directories with separate modules and
> > composition layers and think of better solutions please.
> >
> > There is also a nice comment: "...try to optimize my code around
> > reducing state, coupling, complexity and code, in that order". I
> > understood that like a set of "golden rules":
> > - Make it coupled more tight to decrease (shared) state
> > - Make it more complex to decrease coupling
> > - Make it duplicated to decrease complexity (e.g. abstractions)
> >
> > (tl;dr, I mean it)
> > So, bringing those here.
> > - The shared state is perhaps the Nailgun's world view of all data and
> > versioned serializers for supported releases, which know how to convert
> > the only latest existing data to any of its supported previous versions.
> > - Decoupling we do by putting modules with its compositions to different
> > versioned /etc/puppet subdirectories. I'm not sure how do we decouple
> > Nailgun serializers though.
> > - Complexity is how we compose those modules / write logic of
> serializers.
> > - Duplication is puppet classes (and providers) with slightly different
> > call parameters from a version to version. Sometimes even not backwards
> > compatible. Probably same to the serializers?
> >
> > So, we're going to *increase complexity* by introducing
> > super-compositions for multi OpenStack releases. Not sure about what to
> > happen to the serializers, any volunteers to clarify an impact?. And the
> > Rules "allow" us to do so only in order to decrease either coupling or
> > shared state, which is not the case, AFAICT. Modules with compositions
> > are separated well by OpenStack versions, nothing to decrease. Might
> > that change to decrease a shared state? I'm not sure if it even applies
> > here. Puppet versioning shares nothing. Only Nailgun folks may know the
> > answer.
>
> AFAIK, Nailgun serializers have no shared state and state at all, as
> they always produce the same "data view" for a given version and there
> is no internal state impacting results. Although, they might end up with
> decreased complexity while the orchestration logic - with a drastically
> increased one. It would be hard to determine which deployment graph to
> build from the super-composed multi-release modular tasks, AFAICT. So it
> seems no gain here as well. That means the Golden Rules recommend us to
> not do so :)
>
> >
> > [0]
> >
> https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp
> > [1] https://news.ycombinator.com/item?id=11032296
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> 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/20160218/6d03a511/attachment.html>