Open Stack

On Thu, Feb 18, 2016 at 4:00 AM, Aleksandr Didenko <adidenko at mirantis.com>
wrote:

> > 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.
>
>
I agree it should not be unlimited but it should be created than the 1-1-1
we currently support.  Since we push for upstream openstack puppet to
support current and best effort on current-1, I think being able to support
at least that should be doable.


> 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
>>
>
>
> __________________________________________________________________________
> 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/25f64ea5/attachment.html>