Open Stack

Gary Kotton wrote:
> 
> On 8/12/15, 12:12 AM, "Mike Perez" <thingee at gmail.com> wrote:
>> On 15:39 Aug 11, Gary Kotton wrote:
>>> On 8/11/15, 6:09 PM, "Jay Pipes" <jaypipes at gmail.com> 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.

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.

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/

-- 
Thierry Carrez (ttx)