Open Stack

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" <ihrachys at redhat.com 
> <mailto:ihrachys at 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-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150122/6be58ce2/attachment.html>