<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> So we'll have tons of conditionals in composition layer, right? Even if<br>
> some puppet-openstack class have just one new parameter in new release,<br>
> then we'll have to write a conditional and duplicate class declaration. Or<br>
> write complex parameters hash definitions/merges and use<br>
> create_resources(). The more releases we want to support the more<br>
> complicated composition layer will become. That won't make contribution to<br>
> fuel-library easier and even can greatly reduce development speed. Also are<br>
> we going to add new features to stable releases using this workflow with<br>
> single composition layer?<br>
<br>
As I can see from an example composition [0], such code would be an<br>
unmaintainable burden for development and QA process. Next imagine a<br>
case for incompatible *providers* like network transformations - shall<br>
we put multiple if/case to the ruby providers as well?..<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>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</div><div><br></div><div>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]</div><div><br></div><div>[a] <a href="https://github.com/xarses/fuel-library/blob/9-Kilo/deployment/Puppetfile">https://github.com/xarses/fuel-library/blob/9-Kilo/deployment/Puppetfile</a></div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
That is not a way to go for a composition, sorry. While the idea may be<br>
doable, I agree, but perhaps another way.<br></blockquote><div><br></div><div>Given the requirements to be able to use new features in fuel, with an older version of OpenStack, what alternative would you propose? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(tl;dr)<br>
By the way, this reminded me "The wrong abstraction" [1] article and<br>
discussion. I agree with the author and believe one should not group<br>
code (here it is versioned puppet modules & compositions) in a way which<br>
introduces abstractions (here a super-composition) with multiple<br>
if/else/case and hardcoded things to switch the execution flow based on<br>
version of things. Just keep code as is - partially duplicated by<br>
different releases in separate directories with separate modules and<br>
composition layers and think of better solutions please.<br>
<br>
There is also a nice comment: "...try to optimize my code around<br>
reducing state, coupling, complexity and code, in that order". I<br>
understood that like a set of "golden rules":<br>
- Make it coupled more tight to decrease (shared) state<br>
- Make it more complex to decrease coupling<br>
- Make it duplicated to decrease complexity (e.g. abstractions)<br>
<br>
(tl;dr, I mean it)<br>
So, bringing those here.<br>
- The shared state is perhaps the Nailgun's world view of all data and<br>
versioned serializers for supported releases, which know how to convert<br>
the only latest existing data to any of its supported previous versions.<br>
- Decoupling we do by putting modules with its compositions to different<br>
versioned /etc/puppet subdirectories. I'm not sure how do we decouple<br>
Nailgun serializers though.<br>
- Complexity is how we compose those modules / write logic of serializers.<br>
- Duplication is puppet classes (and providers) with slightly different<br>
call parameters from a version to version. Sometimes even not backwards<br>
compatible. Probably same to the serializers?<br>
<br>
So, we're going to *increase complexity* by introducing<br>
super-compositions for multi OpenStack releases. Not sure about what to<br>
happen to the serializers, any volunteers to clarify an impact?. And the<br>
Rules "allow" us to do so only in order to decrease either coupling or<br>
shared state, which is not the case, AFAICT. Modules with compositions<br>
are separated well by OpenStack versions, nothing to decrease. Might<br>
that change to decrease a shared state? I'm not sure if it even applies<br>
here. Puppet versioning shares nothing. Only Nailgun folks may know the<br>
answer.<br>
<br>
[0]<br>
<a href="https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/281084/1/deployment/puppet/ceph/manifests/nova_compute.pp</a><br>
[1] <a href="https://news.ycombinator.com/item?id=11032296" rel="noreferrer" target="_blank">https://news.ycombinator.com/item?id=11032296</a><br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</div>