Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

2017-05-03 Thread Boden Russell
On 5/3/17 8:55 AM, Eric Fried wrote: > Can you please point to the change(s) that move the constants? Or > provide some other way to figure out which are affected? > This Hound search [1] provides an overall picture and can be honed to specific projects as needed. The search will identify

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

2017-05-03 Thread Eric Fried
Boden- Can you please point to the change(s) that move the constants? Or provide some other way to figure out which are affected? Thanks, Eric (efried) On 05/03/2017 09:30 AM, Boden Russell wrote: > If your project uses

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

2016-11-24 Thread Armando M.
On 24 November 2016 at 10:16, Neil Jerram 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

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

2016-11-24 Thread Neil Jerram
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

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

2016-11-24 Thread Armando M.
On 24 November 2016 at 09:41, Kevin Benton 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

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

2016-11-24 Thread Kevin Benton
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."

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

2016-11-24 Thread Armando M.
On 24 November 2016 at 05:27, Neil Jerram 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,

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

2016-11-24 Thread Neil Jerram
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? On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton wrote: > The issue we had is different than breaking changes in

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

2016-11-23 Thread Armando M.
On 23 November 2016 at 16:42, Joshua Harlow 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

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

2016-11-23 Thread Kevin Benton
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

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

2016-11-23 Thread Joshua Harlow
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...

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

2016-11-23 Thread Boden Russell
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]

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

2016-11-16 Thread Armando M.
ev@lists.openstack.org> > *Date: *Wednesday, November 16, 2016 at 6:16 PM > *To: *OpenStack List <openstack-dev@lists.openstack.org> > *Subject: *Re: [openstack-dev] [neutron] neutron-lib impact > > > > > > > > On 16 November 2016 at 00:55, Gary Kotton &

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

2016-11-16 Thread Gary Kotton
List <openstack-dev@lists.openstack.org> Date: Wednesday, November 16, 2016 at 6:16 PM To: OpenStack List <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron] neutron-lib impact On 16 November 2016 at 00:55, Gary Kotton <gkot...@vmware.com<mai

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

2016-11-16 Thread Armando M.
On 16 November 2016 at 00:55, Gary Kotton 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

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

2016-11-16 Thread Gary Kotton
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. I think that we should only unblock the patch https://review.openstack.org/#/c/386845. I think that due to the fact that