Open Stack

On 24 November 2016 at 10:16, Neil Jerram <neil at tigera.io> wrote:

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

We're asking folks to take a number of steps to properly communicate
potential issues such as those happened during the past 24 hours:

   - Mark a change's commit message with 'NeutronLibImpact' so that it can
   be caught with gerrit filters [1,2]. This helps folks to check for imminent
   potential impact or past impact that one has to catch up to. We have a
   weekly team meeting discussion about such issues to raise visibility.
   - further raise awareness in ML threads, in case offline discussion is
   required.

Monitoring the usual channels (team meeting logs and ML threads) should
give ample notice to folks and instructions on how to react.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
[2]
https://review.openstack.org/#/q/status:merged+message:%22NeutronLibImpact%22


> 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
>>
>
> __________________________________________________________________________
> 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/520992ab/attachment.html>