Open Stack

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

[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