On Wednesday, August 12, 2015, Thierry Carrez <<a href="mailto:thierry@openstack.org">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 href="javascript:;" onclick="_e(event, 'cvml', 'thingee@gmail.com')">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 href="javascript:;" onclick="_e(event, 'cvml', 'jaypipes@gmail.com')">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>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><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><div>This would be backporting a new driver to an older release. That seems like a bad idea.</div><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><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><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><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><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><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><br></div><div>Thanks,</div><div>John</div></div>