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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev