Open Stack

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=bui
>>> ld_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/sou
>>> rce/contributing.rst
>>> [2]
>>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>>> rce/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.op
>>> enstack.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.op
>>> enstack.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.op
>>> enstack.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.op
>>> enstack.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:unsubscrib
>> e
>> 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/aa5ea4e3/attachment.html>