[openstack-dev] [tripleo] Add support for Neutron NSX driver
emilien at redhat.com
Tue Sep 5 17:32:53 UTC 2017
On Tue, Sep 5, 2017 at 10:16 AM, Ben Nemec <openstack at nemebean.com> wrote:
> On 09/04/2017 11:50 PM, Emilien Macchi wrote:
>> On Fri, Sep 1, 2017 at 2:37 PM, Tong Liu <lexuns at gmail.com> wrote:
>>> In pike release, we added supported for Neutron NSX driver in TripleO 
>>> the following patches. This will enable TripleO overcloud deployment to
>>> vmware_nsx as Neutron core_plugin.
>>> However, there are some critical issues which prevent it from functional
>>> correctly, and we fixed them in master with the following patches.
>>> Can we merged these patches and back port to pike?
>> So if we follow all the rules, it goes against how to we handle stable
>> branches and release management in general.
> I don't know that I agree. These patches are all for a feature that merged
> earlier in Pike, but apparently is broken. The only real issue I see is
> that the first one doesn't have a bug reference and thus isn't valid for
> backport as-is. That one might need further discussion, but the others seem
> to be legitimate bug fixes.
> I also don't see any blueprint references, so I'm not sure how that came
> into the discussion. Maybe some confusion about the process for FFE's vs.
> bugs? It doesn't appear to me that a bp should be needed for these changes,
> but maybe I'm missing something.
In that case let's threat them as bug fixes and let's do the backports
>> Usually what happens is we discuss about blueprints at PTG and then
>> during the cycle developers implement the blueprints.
>> Sometimes some blueprint get deferred for some reason (quite often
>> it's because of overcommit but that's a separated topic) so they can
>> as for FFE (feature freeze exception), granted by the PTL.
>> In your case, it's a bit more complex. You created the blueprint a few
>> days before final release of Pike and you're asking us to merge the
>> code AND backport it to Pike.
>> That's for the facts & context, hope it helps to understand why this
>> request is tricky.
>> Now you're a vendor and you're helping to support your driver, which is
>> We'll need to evaluate each commit and see if they are backward
>> compatible and actually don't beak any interface (because we want our
>> stable branches stable).
>> I'm ok to make an exception if next time you can do a better job in
>> scheduling the work that will be done during one cycle.
>> The way we propose blueprint is really lightweight, and in the open,
>> so really no complication here.
>> For now, most of the team is quite busy on Pike release (and PTG
>> coming next week), so I'm not sure your patches will be reviewed soon
>> (if yes, that's good).
>> For the backports, we'll have to evaluate case by case and see if it's
>> Thanks for your work and we hope our collaboration can happen earlier
>> the next time.
>>>  Blueprint:
More information about the OpenStack-dev