[openstack-dev] [neutron] neutron-lib impact

Gary Kotton gkotton at vmware.com
Wed Nov 16 18:11:31 UTC 2016


Hi,
I agree with you on a number of points that you have made below. But you are mixing things up. One you state that we should be moving faster and it is patches like this that actually hinder us. We are not moving as the core team is dwindling down and people are leaving the project. We need to add new members to the core team and remove people who are not taking part. We are a community and not an autocracy. It is great that you are driving this but getting people on board would be helpful. I feel that the cores from the subprojects should chime in and review this – at the end of the day it affects them too. I have even asked other to base reviews on this code. I just think that you need to be aware that there are other people working on the project and that they too should be engaged.
Thanks
Gary

From: "Armando M." <armamig at gmail.com>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
Date: Wednesday, November 16, 2016 at 6:16 PM
To: OpenStack List <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] neutron-lib impact



On 16 November 2016 at 00:55, Gary Kotton <gkotton at vmware.com<mailto:gkotton at vmware.com>> wrote:
Hi,
The directory integration will break all of the plugins and neutron projects. I do not think that this is something that we should do. It breaks the neutron API contract.

The plugin directory is an implementation internal. Let's be very clear, in case you have not realized this already:

Neutron is not supposed to be imported directly by projects and we all knew it when we started off with the project decomposition.

neutron-lib is our response to driving adoption of stable interfaces across the neutron ecosystem of repositories. Forcing ourselves to introduce artificial deprecation cycles for internal details is not only slowing us down but it has proven ineffective so far. We should accelerate with the decoupling of projects so that we can all consider these types of breakages a thing of the past.

I think that we should only unblock the patch https://review.openstack.org/#/c/386845. I think that due to the fact that this patch (very big) will break all plugins, we should only approve it once every sub project owner has chimed in.
This will mean that she/he will need to understand that there may be some tweaks involved in getting unit tests to pass. CI may automagically work.

This is impractical and defeats the point of allowing us to go faster. I have taken the proactive step of announcing this change publicly and with ample notice. I have addressed many subprojects myself and have already seen +2/+1 flocking in. I have moved forward without creating busy work for myself and the review team.

I feel that as a core reviewer my responsibility is to make sure that we do not break things.

We are not in a sane situation. It's been two years since we split the repo up and very little progress has been made to decouple the projects via stable interfaces. I am trying to identify ways to allow us to accelerate and you're stifling that effort with your abuse of core rights. I was not going to let the patch merge without a final announcement at the next team meeting.

In addition to this we have a responsibility to ensure that things continue to work. Hopefully we can find a way to do this in a more friendly manner.

I have taken such a responsibility with [1]. It takes us longer to discuss (on something that was already widely agreed on) than either fixing the breakage or provide a 'fake' backward compat layer which we'll lead to the breakage as soon we take it away [2].

That said, I am happy to concede if other members of the core team agrees with you. As PTL, I have identified a gap that needs to be filled and I am proactively stepping up to address the gap. I can't obviously be right all the time, but I was under the impression I had the majority of the core team on my side.

At this point, I'd invite other neutron core members to review and vote on the patch.

A.

[1] https://review.openstack.org/#/q/topic:plugin-directory
[2]  https://bugs.launchpad.net/vmware-nsx/+bug/1640319

Thanks
Gary

From: "Armando M." <armamig at gmail.com<mailto:armamig at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, November 16, 2016 at 6:51 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [neutron] neutron-lib impact

Hi neutrinos,

As mentioned during the last team meeting [1], there is a change [2] in the works aimed at adopting the neutron plugins directory as provided in neutron-lib 1.0.0 [3].

As shown in [2], the switch to using the directory is relatively straightforward. I leave the rest of the affected repos as an exercise for the reader :)

Cheers,
Armando

[1] http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-11-14-21.00.txt
[2] https://review.openstack.org/#/q/topic:plugin-directory
[3] http://docs.openstack.org/releasenotes/neutron-lib/unreleased.html#id3


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161116/f7fc60b7/attachment.html>


More information about the OpenStack-dev mailing list