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