Re: [openstack-dev] [Fuel] Mitaka stable branch

2016-07-13 Thread Vladimir Kuklin 
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 
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-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
>

Re: [openstack-dev] [Fuel] Mitaka stable branch

2016-07-13 Thread Bogdan Dobrelya 
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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Mitaka stable branch

2016-07-13 Thread Vladimir Kozhukalov 
>
> 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.

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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Mitaka stable branch

2016-07-13 Thread Bogdan Dobrelya 
On 07/13/2016 10:17 AM, Vladimir Kozhukalov wrote:
> Dear colleagues,
> 
> I'd like to announce some of our plans on how we are going to
> support/develop Fuel Mitaka stable branch. The plan is as follows:
> 
> 0) We have been working hard and have fixed a lot of bugs in Mitaka
> branch as for late. This week we are going to announce 9.0.1 release
> which is stable and production ready.
> 
> 1) We are planning to backport onto stable Mitaka branch some (NOT all)
> features that are more or less regression safe. All such features will
> be thoroughly tested so to avoid lack of stability. Given this we expect
> master and stable branches will soon diverge a lot and thus it will soon
> be impossible to just cherry-pick  majority of features and bug fixes
> from master to stable and instead they often are to be re-implemented.
> It will likely require to spend twice as much time as we usually spend
> for every change that is to be landed both in master and stable.
> 
> 2) We are planning to make stable Mitaka branch even more stable and
> continue to fix bugs (even medium and low). We are not planning to
> always follow Stable Branches policy [1] and backport onto stable Mitaka
> branch only those bugs that are already merged to master. Some bugs will
> be first merged to stable and then ported to master. It is just for
> conveniece and development velocity. Since master and stable will
> diverge significantly, it won't make much sense to follow "master first"
> policy. But still all bugs that make sense both for master and for
> stable must be fixed in both these branches.
> 
> 3) Since Mitaka branch is expected to stay stable all the time, we are
> planning to set release tags (9.x) on stable branch approximately every
> month or so. We won't be forced to spend months on code freezing and
> stabilizing and thus we will be able to release features frequently (not
> all features but those are to be backported onto stable branch).

Few Q:
- Is the stable/mitaka the only stable branch in the scope of the changes?

- 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?

> 
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> 
> 
> Vladimir Kozhukalov
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Mitaka stable branch

2016-07-13 Thread Vladimir Kozhukalov 
Dear colleagues,

I'd like to announce some of our plans on how we are going to
support/develop Fuel Mitaka stable branch. The plan is as follows:

0) We have been working hard and have fixed a lot of bugs in Mitaka branch
as for late. This week we are going to announce 9.0.1 release which is
stable and production ready.

1) We are planning to backport onto stable Mitaka branch some (NOT all)
features that are more or less regression safe. All such features will be
thoroughly tested so to avoid lack of stability. Given this we expect
master and stable branches will soon diverge a lot and thus it will soon be
impossible to just cherry-pick  majority of features and bug fixes from
master to stable and instead they often are to be re-implemented. It will
likely require to spend twice as much time as we usually spend for every
change that is to be landed both in master and stable.

2) We are planning to make stable Mitaka branch even more stable and
continue to fix bugs (even medium and low). We are not planning to always
follow Stable Branches policy [1] and backport onto stable Mitaka branch
only those bugs that are already merged to master. Some bugs will be first
merged to stable and then ported to master. It is just for conveniece and
development velocity. Since master and stable will diverge significantly,
it won't make much sense to follow "master first" policy. But still all
bugs that make sense both for master and for stable must be fixed in both
these branches.

3) Since Mitaka branch is expected to stay stable all the time, we are
planning to set release tags (9.x) on stable branch approximately every
month or so. We won't be forced to spend months on code freezing and
stabilizing and thus we will be able to release features frequently (not
all features but those are to be backported onto stable branch).


[1] http://docs.openstack.org/project-team-guide/stable-branches.html


Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev