[openstack-dev] [Fuel] Mitaka stable branch

Bogdan Dobrelya bdobrelia at mirantis.com
Wed Jul 13 09:23:36 UTC 2016


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



More information about the OpenStack-dev mailing list