<div dir="ltr"><div>Hi,</div><div><br></div><div>The Octane team has some issues with lacking definition of what the 'release' is in Fuel (in terms of managed environments). I started an etherpad [1] to summarize the entities/artifacts that consistute a 'release' at the moment. Based on this definition, we can localize and define entry points where the actual 'release'-specific code could be separated from universal frameworks in Nailgun and other component of Fuel. Thus, we could better manage different releases with a single version of Nailgun code, which is essential for the upgrade workflow.<br></div><div><br></div><div>I agree with Alex on that at least a part of the composition layer is bound to be 'release'-specific, especially the puppet modules that deploy OpenStack and other managed components. On the other hand, certain parts of the fuel-library have nothing to do with the managed 'release', and concern the Fuel Admin node itself. It would be useful to make separation along those lines as well.<br></div><div><br></div><div>[1] <a href="https://etherpad.openstack.org/p/fuel-release-definition">https://etherpad.openstack.org/p/fuel-release-definition</a></div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 12:02 PM, Aleksandr Didenko <span dir="ltr"><<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<span class=""><br><br>> So what is open? The composition layer.<br><br></span></div>We can have different composition layers for every release and it's already implemented in releases - separate puppet modules/manifests dir for every release.<span class=""><br><br>> Currently, we just abandon support for previous versions in the 
composition layer and leave them to only be monuments in the 
stable/<release> series branches for maintenance. If we instead 
started making changes (forwards or backwards that) change the calls 
based on the openstack version [5] then we would be able to change the 
calls based on then needs of that release, and the puppet-openstack 
modules we are working with.<br><br></span></div>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?<span class=""><br><br>> Testing master while keeping stable. Given the ability to conditional 
what source of openstack bits, which versions of manifests we can start 
testing both master and keep health on stable. This would help 
accelerate both fuel development and deploying and testing development 
versions of openstack<br><br></span></div>I'm sorry, but I don't see how we can accelerate things by making composition layer more and more complicated. If we're going to run CI and swarm for all of the supported releases on the ISO, that would rather decrease speed of development and testing drastically. Also aren't we "testing both master and keep health on stable" right now by running tests for master and stable versions of Fuel?<span class=""><br><br>> Deploying stable and upgrading later. Again given the ability to deploy 
multiple OpenStack versions within the same Fuel version, teams focused 
on upgrades can take advantage of the latest enhancements in fuel to 
work the upgrade process more easily, as an added benefit this would 
eventually lead to better support for end user upgrades too.<br><br></span></div>Using the same composition layers is not required for this. Also how it differs from using the current upgrade procedure? When you have, for instance, 7.0 release and then upgrade to 8.0, so basically result is the same - you have two releases in Fuel, 2 directories with manifests, 2 repos with packages.<br><div><br><div><span class="">> Deploying older versions, in the odd case that we 
need to take advantage of older OpenStack releases like in the case of 
Kilo with a newer version of Fuel we can easily maintain that version 
too as we can keep the older cases around in the composition layer with 
out adding much burden on the other components.<br><br></span>Using the same composition layers is not required for this, "we can keep the older cases around" in the composition layer of previous version.<br><br>Also, how many releases we're going to support? All of them starting from Kilo? What about ISO size? What about CI, infra (required HW), acceptance testing, etc impact?<br><br></div><div>Regards,<br></div><div>Alex<br></div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Feb 11, 2016 at 6:57 AM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Right now master (targeting 9.0) is still deploying liberty and there is active work going on to support both Kilo and Mitaka. On the review queue are changes that would make fuel-library in-compatible with the prior (liberty) openstack release. However I think if we extend a little bit of effort we can keep some semblance of "support" while creating a pattern for the Kilo support to continue to use. At the same time this pattern can help us test parallel versions as we move through openstack releases and should reduce occurrences of our CI freeze/merge parties <div><br></div><div>What is this magic pattern? Well its already present, and all be it not designed for this I think we could quickly make it work. We use the release fixture already present in fuel. Originally designed to work for upgrades, we could reuse this within the same fuel release to control various aspects needed to deploy a separate openstack version.</div><div><br></div><div>What we need to support multiple OpenStack versions:</div><div>1) Packge repo's that contain the relevant bits. CHECK, this can be toggled with a new release  [1][2]</div><div>2) can point to different Puppet modules CHECK, also in toggled release  [3]</div><div>3) Composition layer that supports calls to different puppet-openstack modules, WIP, it still needs work, but can be done [4]</div><div><br></div><div>So what is open? The composition layer.</div><div><br></div><div>Currently, we just abandon support for previous versions in the composition layer and leave them to only be monuments in the stable/<release> series branches for maintenance. If we instead started making changes (forwards or backwards that) change the calls based on the openstack version [5] then we would be able to change the calls based on then needs of that release, and the puppet-openstack modules we are working with.</div><div><br></div><div>Given that we most of the time we would be supporting the previous release (liberty) (which we should avoid dropping until after dev releases) and the currently under development release (Mitaka), this will give us some magical powers.</div><div><br></div><div>Testing master while keeping stable. Given the ability to conditional what source of openstack bits, which versions of manifests we can start testing both master and keep health on stable. This would help accelerate both fuel development and deploying and testing development versions of openstack</div><div><br></div><div>Deploying stable and upgrading later. Again given the ability to deploy multiple OpenStack versions within the same Fuel version, teams focused on upgrades can take advantage of the latest enhancements in fuel to work the upgrade process more easily, as an added benefit this would eventually lead to better support for end user upgrades too.</div><div><br></div><div>Deploying older versions, in the odd case that we need to take advantage of older OpenStack releases like in the case of Kilo with a newer version of Fuel we can easily maintain that version too as we can keep the older cases around in the composition layer with out adding much burden on the other components.</div><div><br></div><div>[1] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1957</a></div><div>[2] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1906</a></div><div><br></div><div>[3] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1371</a></div><div><br></div><div>[4] <a href="https://github.com/xarses/fuel-library/tree/9-Kilo" target="_blank">https://github.com/xarses/fuel-library/tree/9-Kilo</a> </div><div><br><div>[5] <a href="https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948" target="_blank">https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L1948</a> </div></div></div><span><font color="#888888"><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>
</font></span><br></div></div>__________________________________________________________________________<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>
<br></blockquote></div><br></div>
<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>
<br></blockquote></div><br></div>