Open Stack

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