Open Stack

On Wednesday, August 12, 2015, Thierry Carrez <thierry at openstack.org> wrote:

> Gary Kotton wrote:
> >
> > On 8/12/15, 12:12 AM, "Mike Perez" <thingee at gmail.com <javascript:;>>
> wrote:
> >> On 15:39 Aug 11, Gary Kotton wrote:
> >>> On 8/11/15, 6:09 PM, "Jay Pipes" <jaypipes at gmail.com <javascript:;>>
> wrote:
> >>>
> >>>> Are you saying that *new functionality* was added to the stable/kilo
> >>>> branch of *Neutron*, and because new functionality was added to
> >>>> stable/kilo's Neutron, that stable/kilo *Nova* will no longer work?
> >>>
> >>> Yes. That is exactly what I am saying. The issues is as follows. The
> >>> NSXv
> >>> manager requires the virtual machines VNIC index to enable the security
> >>> groups to work. Without that a VM will not be able to send and receive
> >>> traffic. In addition to this the NSXv plugin does not have any agents
> so
> >>> we need to do the metadata plugin changes to ensure metadata support.
> So
> >>> effectively with the patches: https://review.openstack.org/209372 and
> >>> https://review.openstack.org/209374 the stable/kilo nova code will not
> >>> work with the stable/kilo neutron NSXv plugin.
> >> <snip>
> >>
> >>> So what do you suggest?
> >>
> >> This was added in Neutron during Kilo [1].
> >>
> >> It's the responsibility of the patch owner to revert things if something
> >> doesn't land in a dependency patch of some other project.
> >>
> >> I'm not familiar with the patch, but you can see if Neutron folks will
> >> accept
> >> a revert in stable/kilo. There's no reason to get other projects
> involved
> >> because this wasn't handled properly.
> >>
> >> [1] - https://review.openstack.org/#/c/144278/
> >
> > So you are suggesting that we revert the neutron plugin? I do not think
> > that a revert is relevant here.
>
> Yeah, I'm not sure reverting the Neutron patch would be more acceptable.
> That one landed in Neutron kilo in time.
>
> The issue here is that due to Nova's review velocity during the kilo
> cycle (and arguably the failure to raise this as a cross-project issue
> affecting the release), the VMware NSXv support was shipped as broken in
> Kilo, and requires non-trivial changes to get fixed.


I see this as Nova not shipping with VMware NSXv support in kilo, the
feature was never completed, rather than it being broken. I could be
missing something, but I also know that difference doesn't really help
anyone.


> We have two options: bending the stable rules to allow the fix to be
> backported, or document it as broken in Kilo with the invasive patches
> being made available for people and distributions who still want to
> apply it.
>
> Given that we are 4 months into Kilo, I'd say stable/kilo users are used
> to this being broken at this point, so my vote would go for the second
> option.


This would be backporting a new driver to an older release. That seems like
a bad idea.


> That said, we should definitely raise [1] as a cross-project issue and
> see how we could work it into Liberty, so that we don't end up in the
> same dark corner in 4 months. I just don't want to break the stable
> rules (and the user confidence we've built around us applying them) to
> retroactively pay back review velocity / trust issues within Nova.
>
> [1] https://review.openstack.org/#/c/165750/
>
>
So this is the same issue. The VMware neutron driver has merged support for
a feature where we have not managed to get into Nova yet.

First the long term view...

This is happening more frequently with Cinder drivers/features, Neutron
things, and to a lesser extent Glance.

The great work the Cinder folks have done with brick, is hopefully going to
improve the situation for Cinder. There are a group of folks working on a
similar VIF focused library to help making it easier to add support for new
Neutron VIF drivers without needing to merge things in Nova.

Right now those above efforts are largely focused on libvirt, but using
oslo.vmware, or probably something else, I am sure we could evolve
something similar for VMware, but I haven't dug into that.

There are lots of coding efforts and process efforts to make the most of
our current review bandwidth and to expand that bandwidth, but I don't
think it's helpful to get into that here.

So, more short term and specific points...

This patch had no bug or blueprint attached. It eventually got noticed a
few weeks after the blueprint freeze. It's hard to track cross project
dependencies if we don't know they exist. None of the various escalation
paths raised this patch. None of those things are good, they happened,
things happen.

Now it's a priority call. We have already delayed several blueprints (20 or
30) to try and get as many bugs fixed on features that have already made it
into tree (we already have a backlog of well over 100 bug patches to
review) and keep the priorities moving forward (that are mostly to help
us go faster in the near future).

Right now my gut tells me, partly in fairness to all the other things we
have just not managed to get reviewed that did follow the process and met
all the deadlines but were also unable to get merged, we should wait until
Mitaka for this one, and in the meantime look at ways to get VMware to
adopt some of the strategies of splitting out code that the libvirt driver
is working on, so we can make these things easier to land in the future.

Now I am guessing there could be a side of this I am totally missing, but
this feels like the best way forward right now, looking at the whole
community.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150813/40fa748c/attachment.html>