<div dir="ltr"><div><div><div>> This requires the loss of all of the features in the newer version of
fuel since it relies on the older version of the serialized data from
nailgun.<br><div></div><br></div><div>Yes. But isn't it how "stable" branches are supposed to work? Introducing new features into "stable" branches will make them not so "stable", right? Even if these new features are introduced in composition layer or configuration data. just an example: network transformations in astute.yaml that are being translated into actual network configuration.<br></div><div><br>> Yes, this is, in part, about taking advantage of new fuel features
on stable openstack releases, we are almost always behind and the
previous release(s) supported this already. <br><br>Introducing new features to stable releases will require full cycle of testing. So, basically, it will affect the whole development process.<br><br>> In addtion we currently don't allow for new clusters to be deployed this way.<br><br></div>We can remove this restriction. Nailgun is able to serialize data for previous releases because that's how it supports adding new nodes to older environments after upgrade, so it should not be a problem.<br><br></div>Regards,<br></div>Alex<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 10:19 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.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"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Thu, Feb 11, 2016 at 1:03 AM Aleksandr Didenko <<a href="mailto:adidenko@mirantis.com" target="_blank">adidenko@mirantis.com</a>> wrote:<br></div><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,</div></div></div></div></div><div dir="ltr"><div><div><div><div><br><br>> So what is open? The composition layer.<br><br></div></div></div></div></div><div dir="ltr"><div><div><div><div></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.</div></div></div></div></blockquote><div><br></div></span><div>This requires the loss of all of the features in the newer version of fuel since it relies on the older version of the serialized data from nailgun. In addtion we currently don't allow for new clusters to be deployed this way.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><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></div></div></div></div><div dir="ltr"><div><div><div></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?</div></div></div><div dir="ltr"><div><div><br></div></div></div></blockquote></span><div>Yes, we need conditionals in the composition layer, we already need these to no jam the gate when we switch between stable and master, we might as well maintain them properly so that we can start running multiple versions</div><div><br></div><div>Yes, this is, in part, about taking advantage of new fuel features on stable openstack releases, we are almost always behind and the previous release(s) supported this already. </div><div><br></div><div>If its only supported in the newer version, then we would have a similar problem with enabling the feature anyways as our current process results in us developing on stable openstack with the newer fuel until late in the cycle, when we switch packaging over.</div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><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></div></div></div><div dir="ltr"><div><div></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?</div></div><div dir="ltr"><div><br></div></div></blockquote></span><div>No, this is about deploying stable and master from the same version of Fuel, with the new features from fuel. As we develop new features in fuel we frequently run into problems simply because openstack version we are deploying is broken, this would allow for gating on stable and edge testing master until it can become the new stable. </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><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></div></div><div dir="ltr"><div></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.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br><div></div></div></div><div dir="ltr"><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.<br><br></div></div></div><div dir="ltr"><div><div>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></div></div></div></blockquote><div><br></div></span><div>Again, we lose compatibility with the data from nailgun by simply pulling in the old composition layer, we loose all new features that the composition layer exposes </div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><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></div></div></div></blockquote><div><br></div></span><div>On average, two openstack releases would be supported the version that this fuel is being developed for, and the prior stable openstack release. There is an abnormal exception for Kilo. For 9 I would propose Kilo and Mitaka if we want to keep it to just two.</div><div><br></div><div>ISO size, only one release should be bundled on the ISO, the other can exist on the external package repos. the default release should be included by default We would want to add parameter to pick this for during build if someone wanted the other version</div><div><br></div><div>For the normal workflow (as an extension of how we function currently anyway). We would gate the fuel cycle on the stable release and have a non-voting basic test on master version. We would run regular BVT on both. When we are ready to switch to the master release because of RC availability or other high stability, then we would flip this. Stable would become basic non-voting test and "master" (at this point new stable) would get the gate</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><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><div class="gmail_extra"><div class="gmail_quote">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><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">__________________________________________________________________________<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>
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><div class="HOEnZb"><div class="h5"><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>
</div></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>