Open Stack

On 16 November 2016 at 10:11, Gary Kotton <gkotton at vmware.com> wrote:

> 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.
>

What's this thread for then if not engaging/inviting people to review? Your
point seems moot.


> 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> 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>
> *Reply-To: *OpenStack List <openstack-dev at lists.openstack.org>
> *Date: *Wednesday, November 16, 2016 at 6:51 AM
> *To: *OpenStack List <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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at 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/7160c193/attachment.html>