Open Stack

Bogdan, Vladimir

*Regarding upgrades of Fuel Master Node and environments. *

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):

https://review.openstack.org/#/c/333845/

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.

*Regarding environments upgrades*

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.

*Conclusion*

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.

On Wed, Jul 13, 2016 at 12:23 PM, Bogdan Dobrelya <bdobrelia at mirantis.com>
wrote:

> On 07/13/2016 11:08 AM, Vladimir Kozhukalov wrote:
> >
> >
> >     Few Q:
> >     - Is the stable/mitaka the only stable branch in the scope of the
> >     changes?
> >
> > ​Yes, this announce is only about Mitaka branch. All other stable
> > branches are to be treated as usual, i.e. no feature backports, bug
> > fixes only following "master first" policy, etc.
> >
> >
> >     - As the master and stable/mitaka will diverge, the former might
> contain
> >     backwards incompatible changes, ending up the upgrade paths from
> >     stable/mitaka to future >=10.x releases will likely be *blocked* for
> its
> >     life time. Any plans how to address that?
> >
> >     - What about upgrade paths availability from the stable/* branches
> to:
> >       a) stable/mitaka
> >       b) future >=10.x releases?
> >
> > ​Fortunately, Fuel now has nice built-in LCM that allows to run
> > complicated custom scenarios (including reconfigurations/upgrades of
> > existent OpenStack clusters). Vladimir Kuklin is working hard on making
> > this LCM capabilities applicable to cases stable/* -> stable/mitaka. I
> > believe later we'll be able to implement stable/mitaka -> Newton, etc.
>
> That's OK for the upgrade process, while I'm not sure in the very
> upgrade *possibility* if we allowed backwards incompatible changes make
> it to the Newton. How would users upgrade from stable/mitaka to anything
> wich might be backwards incompatible and might break things? And
> features backported and being developed in both branches may conflict as
> well. All of this makes the upgrade barely possible, so any ideas how
> could we address that?
>
> >
> > Let's try to imagine we removed old role based serializers from Nailgun
> > in Newton release. The question is how are we going, for example, to
> > add/remove nodes to/from Kilo/Liberty clusters. The answer would be we
> > could add custom task graph and task based deployment engine to modify
> > old clusters. I'd like Vladimir Kuklin to give some additional details.
> >
> >
> >
> >
> >     >
> >
>  __________________________________________________________________________
> >     > OpenStack Development Mailing List (not for usage questions)
> >     > Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >     >
> >
> >
> >     --
> >     Best regards,
> >     Bogdan Dobrelya,
> >     Irc #bogdando
> >
> >
>  __________________________________________________________________________
> >     OpenStack Development Mailing List (not for usage questions)
> >     Unsubscribe:
> >     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160713/ba3bfabc/attachment.html>