[openstack-dev] [tripleo] Add support for Neutron NSX driver
openstack at nemebean.com
Tue Sep 5 17:16:33 UTC 2017
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  by
>> the following patches. This will enable TripleO overcloud deployment to use
>> 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.
> 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 good.
> 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 possible.
> Thanks for your work and we hope our collaboration can happen earlier
> the next time.
>>  Blueprint:
More information about the OpenStack-dev