<div dir="ltr">Bogdan, Vladimir<div><br></div><div><b>Regarding upgrades of Fuel Master Node and environments. </b></div><div><br></div><div>First, regarding Fuel Master Node upgrades and enablement of usage of 9.0 LCM features with older clusters. It is assumed that we test usability of Fuel Mitaka code with already deployed clusters, e.g. 8.0, 7.0 and so on. Whenever an issue arise, we fix it. This would allow us to reuse newest features to be able to enable LCM and newest orchestration and integration capabilities with older clusters by essentially, calling old serializers code within extensions pipeline, applying some pre- and postprocessing to the serialized data. Here is an example of how it is done (Work in progress):</div><div><br></div><div><a href="https://review.openstack.org/#/c/333845/">https://review.openstack.org/#/c/333845/</a> <br></div><div><br></div><div>This is an extension that first runs new LCM serializer which data is not compatible with 9.0, but part of which we need for LCM engine (e.g. 'cluster context'), then we simply run 8.0 Serializer, add cluster info into serialized data and then we just update 'upload_configuration' and related tasks by simply copying them from Mitaka code of Fuel Library. I proof-tested this by adding Sahara into already installed 8.0 cluster with BVT scenario and it seems to be working.</div><div><br></div><div><b>Regarding environments upgrades</b></div><div><br></div><div>Having completed item #1 we should be able to run new orchestration against old clusters, so that we can upgrade environments to newer versions, esentially, by rolling reinstallation of control plane and resource nodes, which means that as soon as new version of installed software (including OpenStack, LMA toolchaing and other stuff) works fine with the feature-set specified within the old cluster configuration, it should be OK to do so, but this basically becomes a matter of building consistent upgrade path for the particular environment.</div><div><br></div><div><b>Conclusion</b></div><div><b><br></b></div><div>Let's add bugfixing for management of old clusters and pre-9.0 clusters LCM support into our RoadMap and we should be safe to go.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 12:23 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/13/2016 11:08 AM, Vladimir Kozhukalov wrote:<br>
><br>
><br>
> Few Q:<br>
> - Is the stable/mitaka the only stable branch in the scope of the<br>
> changes?<br>
><br>
> Yes, this announce is only about Mitaka branch. All other stable<br>
> branches are to be treated as usual, i.e. no feature backports, bug<br>
> fixes only following "master first" policy, etc.<br>
><br>
><br>
> - As the master and stable/mitaka will diverge, the former might contain<br>
> backwards incompatible changes, ending up the upgrade paths from<br>
> stable/mitaka to future >=10.x releases will likely be *blocked* for its<br>
> life time. Any plans how to address that?<br>
><br>
> - What about upgrade paths availability from the stable/* branches to:<br>
> a) stable/mitaka<br>
> b) future >=10.x releases?<br>
><br>
> Fortunately, Fuel now has nice built-in LCM that allows to run<br>
> complicated custom scenarios (including reconfigurations/upgrades of<br>
> existent OpenStack clusters). Vladimir Kuklin is working hard on making<br>
> this LCM capabilities applicable to cases stable/* -> stable/mitaka. I<br>
> believe later we'll be able to implement stable/mitaka -> Newton, etc.<br>
<br>
</span>That's OK for the upgrade process, while I'm not sure in the very<br>
upgrade *possibility* if we allowed backwards incompatible changes make<br>
it to the Newton. How would users upgrade from stable/mitaka to anything<br>
wich might be backwards incompatible and might break things? And<br>
features backported and being developed in both branches may conflict as<br>
well. All of this makes the upgrade barely possible, so any ideas how<br>
could we address that?<br>
<span class=""><br>
><br>
> Let's try to imagine we removed old role based serializers from Nailgun<br>
> in Newton release. The question is how are we going, for example, to<br>
> add/remove nodes to/from Kilo/Liberty clusters. The answer would be we<br>
> could add custom task graph and task based deployment engine to modify<br>
> old clusters. I'd like Vladimir Kuklin to give some additional details.<br>
><br>
><br>
><br>
><br>
> ><br>
> __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe:<br>
> <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>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<span class="">> > <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>
><br>
><br>
> --<br>
> Best regards,<br>
> Bogdan Dobrelya,<br>
> Irc #bogdando<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <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>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
<div class="HOEnZb"><div class="h5">><br>
><br>
><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>
><br>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>