Re: [openstack-dev] [stable][neutron] backports vs. vendor decomposition

2015-01-22 Thread Ihar Hrachyshka

There is a proposal from Armando to clear this up:
https://review.openstack.org/#/c/148745/

On 01/22/2015 03:53 PM, Sukhdev Kapur wrote:


Hi Ihar,

I have added this on the agenda for next neutron core meeting to discuss.

This email gives an excellent context to the issue at hand. Only one 
thing I would like to add is that the deadline for stable/juno is only 
one week away - hence, it raises the urgency to call for action.


Thanks

-Sukhdev



On Jan 21, 2015 1:43 PM, Ihar Hrachyshka ihrac...@redhat.com 
mailto:ihrac...@redhat.com wrote:


 Hi all,

 as per: 
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst, 
neutron is going to spin off vendor plugins into separate trees 
outside of neutron core team control. This raises several questions on 
how we are going to handle stable branches that will still include 
plugin code for several cycles.


 1) If a plugin is already spinned off and a patch is applicable for 
stable branches, there are two cases:

 - patch is not merged into vendor repo;
 - patch is merged into the vendor repo.

 My take is:
 - if it's merged in the vendor repo, then we just cherry-pick from 
there (it should just work if vendor repo was created with the whole 
master history saved).
 - if it's not merged into the repo, I would recommend the author to 
propose and merge it there first. If there are any justifiable issues 
with proposing it for vendor repo inclusion, then we can consider 
stable-only merge.


 2) If a plugin is in the middle of spinning off and a patch is 
applicable for stable branch, then there are two options:
 - require plugin to spin off first and then apply the patch to 
vendor repo, or
 - allow some types of patches to be merged into master while vendors 
are working on spinning off the code.


 Examples of those patches are:
 - https://review.openstack.org/#/c/147976/
 - https://review.openstack.org/#/c/148369/

 Currently the patches above are blocked for master inclusion 
assuming the spin off must take place first, and then bugs should be 
fixed in vendor repo. At the same time, we usually avoid backports 
unless the code is not in master anymore, but that's not the case 
here. So the current approach effectively blocks any bug fixes for 
plugins in stable branches.


 If we would be sure that a plugin is out of the tree till Kilo, then 
it would indeed be a waste of time to review the code for 
neutron/master since it would be guaranteed to be released as a 
separate packagr e anyway. In that case, it would be ok to forbid any 
patches for the  plugin code till its spin off from master, and the 
patch would go directly to stable branches.


 That said, it would potentially introduce regressions if we consider 
upgrades from Juno to Kilo + vendor repo. We may say that since the 
regression would be on vendor plugin side, and neutron team does not 
have anything to do with spinned off plugins, that would be fine for us.


 But: we cannot guarantee that a plugin wil leave the neutron tree 
this cycle. The spec explicitly gives permission to stay in the tree 
till L-cycle, and in that case it will be our responsibility to handle 
regressions in Kilo that we may introduce by blocking master fixes.


 I think we should try to set procedure that would avoid potential 
regressions even if they will come from vendor repos.


 We allow fixes that are not applicable for final releases for master 
if it's to be backported in stable branches. F.e. see 
https://review.openstack.org/#/c/127633/ that was merged into master 
while pecan migration should make it useless for Kilo.


 It's my belief plugin code bug fixes in stable branches should be 
treated the same way.


 That said, we should expect vendors to run third party CI for stable 
branches if they want to see backports merged in.


 ***
 I think the correct approach here is:
 - once a plugin is spinned off, consider it is a 'master' for the 
code, and backport to stable branches directly from there;
 - before a plugin is spinned off, assume that it's not going to be 
spinned off in Kilo, and hence allow bug fixes in neutron/master (but 
not new features);
 - once we get to L release that requires all vendor plugin to go 
out, forbid any fixes for the code, assuming they will either spin off 
or will be dropped anyway.

 ***

 The approach is pretty similar to how oslo project handles new 
library spin-offs from oslo-incubator. Yes, there is a difference 
here: in neutron, we loose any control on spinned off repos. Though I 
don't feel it justifies stable-only fixes while we can easily add 
value to vendor code by asking people to consider fixing the bug there 
first. More importantly, nothing should justify blocking bug fixing 
for stable branches.


 Thoughts?

 /Ihar

 
__

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 

Re: [openstack-dev] [stable][neutron] backports vs. vendor decomposition

2015-01-22 Thread Sukhdev Kapur
Hi Ihar,

I have added this on the agenda for next neutron core meeting to discuss.

This email gives an excellent context to the issue at hand. Only one thing
I would like to add is that the deadline for stable/juno is only one week
away - hence, it raises the urgency to call for action.

Thanks

-Sukhdev



On Jan 21, 2015 1:43 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 Hi all,

 as per:
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst,
neutron is going to spin off vendor plugins into separate trees outside of
neutron core team control. This raises several questions on how we are
going to handle stable branches that will still include plugin code for
several cycles.

 1) If a plugin is already spinned off and a patch is applicable for
stable branches, there are two cases:
 - patch is not merged into vendor repo;
 - patch is merged into the vendor repo.

 My take is:
 - if it's merged in the vendor repo, then we just cherry-pick from there
(it should just work if vendor repo was created with the whole master
history saved).
 - if it's not merged into the repo, I would recommend the author to
propose and merge it there first. If there are any justifiable issues with
proposing it for vendor repo inclusion, then we can consider stable-only
merge.

 2) If a plugin is in the middle of spinning off and a patch is applicable
for stable branch, then there are two options:
 - require plugin to spin off first and then apply the patch to vendor
repo, or
 - allow some types of patches to be merged into master while vendors are
working on spinning off the code.

 Examples of those patches are:
 - https://review.openstack.org/#/c/147976/
 - https://review.openstack.org/#/c/148369/

 Currently the patches above are blocked for master inclusion assuming the
spin off must take place first, and then bugs should be fixed in vendor
repo. At the same time, we usually avoid backports unless the code is not
in master anymore, but that's not the case here. So the current approach
effectively blocks any bug fixes for plugins in stable branches.

 If we would be sure that a plugin is out of the tree till Kilo, then it
would indeed be a waste of time to review the code for neutron/master since
it would be guaranteed to be released as a separate packagr e anyway. In
that case, it would be ok to forbid any patches for the  plugin code till
its spin off from master, and the patch would go directly to stable
branches.

 That said, it would potentially introduce regressions if we consider
upgrades from Juno to Kilo + vendor repo. We may say that since the
regression would be on vendor plugin side, and neutron team does not have
anything to do with spinned off plugins, that would be fine for us.

 But: we cannot guarantee that a plugin wil leave the neutron tree this
cycle. The spec explicitly gives permission to stay in the tree till
L-cycle, and in that case it will be our responsibility to handle
regressions in Kilo that we may introduce by blocking master fixes.

 I think we should try to set procedure that would avoid potential
regressions even if they will come from vendor repos.

 We allow fixes that are not applicable for final releases for master if
it's to be backported in stable branches. F.e. see
https://review.openstack.org/#/c/127633/ that was merged into master while
pecan migration should make it useless for Kilo.

 It's my belief plugin code bug fixes in stable branches should be treated
the same way.

 That said, we should expect vendors to run third party CI for stable
branches if they want to see backports merged in.

 ***
 I think the correct approach here is:
 - once a plugin is spinned off, consider it is a 'master' for the code,
and backport to stable branches directly from there;
 - before a plugin is spinned off, assume that it's not going to be
spinned off in Kilo, and hence allow bug fixes in neutron/master (but not
new features);
 - once we get to L release that requires all vendor plugin to go out,
forbid any fixes for the code, assuming they will either spin off or will
be dropped anyway.
 ***

 The approach is pretty similar to how oslo project handles new library
spin-offs from oslo-incubator. Yes, there is a difference here: in neutron,
we loose any control on spinned off repos. Though I don't feel it justifies
stable-only fixes while we can easily add value to vendor code by asking
people to consider fixing the bug there first. More importantly, nothing
should justify blocking bug fixing for stable branches.

 Thoughts?

 /Ihar

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