Open Stack

To be clear, when I said 'catching such issues', what I meant was: 'letting
me know promptly that I now need to update networking-calico'.

I absolutely did not mean any kind of delaying or blocking a neutron or
neutron-lib change.

Thanks,
     Neil


On Thu, Nov 24, 2016 at 5:43 PM Kevin Benton <kevin at benton.pub> wrote:

> Yeah, in this case I don't think it would have helped because it was
> removing several things from neutron simultaneously. The only thing that
> would have stopped that would have been jobs from all sub projects voting
> on each neutron change.
>
> On Nov 24, 2016 10:02, "Armando M." <armamig at gmail.com> wrote:
>
>
>
> On 24 November 2016 at 05:27, Neil Jerram <neil at tigera.io> wrote:
>
> But I think a periodic check for a Neutron/neutron-lib-using project (such
> as networking-calico) would still be a decent way of catching such issues,
> wouldn't it?
>
>
> It depends, and it would. There are many factors at play, as Kevin pointed
> out.
>
>
>
>
> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton <kevin at benton.pub> wrote:
>
> The issue we had is different than breaking changes in neutron-lib. The
> issue we are running into now is bumps in the road when we are removing
> deprecated things from Neutron that other projects are still using even
> though they should be using the neutron-lib version instead.
>
> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow <harlowja at fastmail.com>
> wrote:
>
> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
>
> http://status.openstack.org/openstack-health/#/?groupKey=build_name&resolutionKey=hour&searchProject=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>
> -Josh
>
>
> Boden Russell wrote:
>
> I would encourage anyone working on neutron-lib related changes to have
> a peek at the recently renovated contributing doc [1] if you haven't
> already.
>
> In particular the 'Phase 4: Consume' section [2] provides some tips on
> how we see this workflow playing out.
>
> Thanks
>
> [1]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
> [2]
>
> https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume
>
>
> On 11/23/16 12:39 PM, Armando M. wrote:
>
> Hi neutrinos,
>
> In the last few hours a couple of changes landed [1,2] that caused a bit
> of a jam in the neutron subproject gates, as they overlapped with
> another change [3] having impact on the subprojects.
>
> This is why it is important to communicate during team meetings and/or
> ML that patches with potential impact are in flight in our review
> pipeline, so that we do our best to coordinate the merge process without
> shooting ourselves in the foot.
>
> To bring this back to sanity, I issued a temporary revert [4], so that
> [5] can land undisturbed. After that, a double revert will be applied,
> once subprojects have had the opportunity to deal with the aftermath of
> the other breaking change [1,2] (e.g. [6,7]).
>
>  From now on, I'd strongly encourage people proposing/reviewing patches
> with potential impact (any impact) to err on the side of caution, and
> take the advised steps to ensure such situations don't happen in the
> future.
>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/397704/
> [2] https://review.openstack.org/#/c/397037/
> [3] https://review.openstack.org/#/c/386845/
> [4] https://review.openstack.org/#/c/401377/
> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
> [6] https://review.openstack.org/#/c/401263/
> [7] https://review.openstack.org/#/c/401355/
>
>
> __________________________________________________________________________
> 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
>
>
> __________________________________________________________________________
> 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
>
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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/20161124/06fd710e/attachment-0001.html>