Open Stack

On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya <bdobrelia at mirantis.com>
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?..
>

No, part of the point of reusing the current serializers from nailgun and
the current composition layer / fuel-library is exactly to avoid this kind
of issue. The other point is to take advantage of new features in the new
version of Fuel

The conditions needed in the composition layer are only to the underlying
puppet-openstack modules, which would be rolled back to version that
matches the openstack versions [a]

[a] https://github.com/xarses/fuel-library/blob/9-Kilo/deployment/Puppetfile

>
> That is not a way to go for a composition, sorry. While the idea may be
> doable, I agree, but perhaps another way.
>

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

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

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

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