<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 August 2015 at 09:50, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wednesday, August 12, 2015, Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Gary Kotton wrote:<br>
><br>
> On 8/12/15, 12:12 AM, "Mike Perez" <<a>thingee@gmail.com</a>> wrote:<br>
>> On 15:39 Aug 11, Gary Kotton wrote:<br>
>>> On 8/11/15, 6:09 PM, "Jay Pipes" <<a>jaypipes@gmail.com</a>> wrote:<br>
>>><br>
>>>> Are you saying that *new functionality* was added to the stable/kilo<br>
>>>> branch of *Neutron*, and because new functionality was added to<br>
>>>> stable/kilo's Neutron, that stable/kilo *Nova* will no longer work?<br>
>>><br>
>>> Yes. That is exactly what I am saying. The issues is as follows. The<br>
>>> NSXv<br>
>>> manager requires the virtual machines VNIC index to enable the security<br>
>>> groups to work. Without that a VM will not be able to send and receive<br>
>>> traffic. In addition to this the NSXv plugin does not have any agents so<br>
>>> we need to do the metadata plugin changes to ensure metadata support. So<br>
>>> effectively with the patches: <a href="https://review.openstack.org/209372" target="_blank">https://review.openstack.org/209372</a> and<br>
>>> <a href="https://review.openstack.org/209374" target="_blank">https://review.openstack.org/209374</a> the stable/kilo nova code will not<br>
>>> work with the stable/kilo neutron NSXv plugin.<br>
>> <snip><br>
>><br>
>>> So what do you suggest?<br>
>><br>
>> This was added in Neutron during Kilo [1].<br>
>><br>
>> It's the responsibility of the patch owner to revert things if something<br>
>> doesn't land in a dependency patch of some other project.<br>
>><br>
>> I'm not familiar with the patch, but you can see if Neutron folks will<br>
>> accept<br>
>> a revert in stable/kilo. There's no reason to get other projects involved<br>
>> because this wasn't handled properly.<br>
>><br>
>> [1] - <a href="https://review.openstack.org/#/c/144278/" target="_blank">https://review.openstack.org/#/c/144278/</a><br>
><br>
> So you are suggesting that we revert the neutron plugin? I do not think<br>
> that a revert is relevant here.<br>
<br>
Yeah, I'm not sure reverting the Neutron patch would be more acceptable.<br>
That one landed in Neutron kilo in time.<br>
<br>
The issue here is that due to Nova's review velocity during the kilo<br>
cycle (and arguably the failure to raise this as a cross-project issue<br>
affecting the release), the VMware NSXv support was shipped as broken in<br>
Kilo, and requires non-trivial changes to get fixed.</blockquote><div><br></div></div></div><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have two options: bending the stable rules to allow the fix to be<br>
backported, or document it as broken in Kilo with the invasive patches<br>
being made available for people and distributions who still want to<br>
apply it.<br>
<br>
Given that we are 4 months into Kilo, I'd say stable/kilo users are used<br>
to this being broken at this point, so my vote would go for the second<br>
option.</blockquote><div><br></div></span><div>This would be backporting a new driver to an older release. That seems like a bad idea.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, we should definitely raise [1] as a cross-project issue and<br>
see how we could work it into Liberty, so that we don't end up in the<br>
same dark corner in 4 months. I just don't want to break the stable<br>
rules (and the user confidence we've built around us applying them) to<br>
retroactively pay back review velocity / trust issues within Nova.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/165750/" target="_blank">https://review.openstack.org/#/c/165750/</a><br>
<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>First the long term view...</div><div><br></div><div>This is happening more frequently with Cinder drivers/features, Neutron things, and to a lesser extent Glance.</div><div><br></div>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.<div><br></div><div>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.</div></blockquote><div><br></div><div>That is definetely the way to go in my opinion. I reckon VIF plugging is an area where there is a lot of coupling with Neutron, and "decentralizing" will be definetely beneficial for both contributors and reviewers. It should be ok to have a VMware-specific VIF library - it would not work really like cinderbrick, but from the nova perspective I think this does not matter.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>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.</div><div><br></div><div>So, more short term and specific points...</div><div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>The blueprint was indeed attached to the commit message only on the last patchset. This has been handled poorly by the VMware team.<br></div><div>As you said, things happen. As a result, the patch was pretty much now only to the submitter and a few other folks.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div>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).<br></div></blockquote><div><br></div><div>Priority and common sense, I would say!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>From a fairness perspective I guess you are correct. If you agree to merge this patch, then somebody who got a blueprint delayed might rightfully complain.<br></div><div>There is also the fundamental apsect that the VMware team has been far from proactive - especially because of lack of reviews from SMEs, an issue which must and will definetely fixed.<br><br></div><div>The common sense perspective is probably just a tad different. The patch looks really low-risk (at least to me). Technically speaking it's not even a new feature, but adapts an existing feature to changes being introduced in openstack/vmware-nsx for Liberty. Delaying it will either break support on trunk code, or force the vmware-nsx team to revert changes in Neutron and revise the strategy for Liberty.<br></div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I think it all boils down to see how many of the delayed blueprints presented characteristics similar to this one. If there are other relatively low-risk, driver-specific blueprints with small code patches to review which have been delayed, then hands down - merging this will be absolutely unfair for the whole community.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>Thanks,</div><div>John</div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>