[openstack-dev] [Neutron] - breaking changes for plugins/drivers

Assaf Muller amuller at redhat.com
Thu Jul 2 14:07:00 UTC 2015



----- Original Message -----
> 
> 
> I think we need to revisit the test infrastructure requirement. We have a lot
> of logic to setup and test plugins/drivers and making each repo duplicate
> all of that is a pretty big waste of effort. Maybe some base stuff should go
> in neutron lib?

Absolutely.

> On Jul 1, 2015 12:32 PM, "Doug Wiegley" < dougwig at parksidesoftware.com >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> On Jun 30, 2015, at 11:22 PM, Kevin Benton < blak111 at gmail.com > wrote:
> 
> Hi,
> 
> We have had at least two breaking changes merge this week for out-of-tree
> drivers/plugins. These are just the two I noticed that broke the Big Switch
> CI (the one I keep an eye on since I had set it up):
> 
> 1. Removed test_lib that changes config files.
> https://review.openstack.org/#/c/196583/
> 2. Removed the loopingcall common util with no deprecation cycle or
> announcement. https://review.openstack.org/#/c/192999/
> 
> I proposed a revert for 1 that merged, but I don't particularly want to keep
> fighting this. What is our current policy on this? Just change whatever we
> want and tell plugin maintainers this is just the way things work?
> 
> So, this is a big hairy bit of suck right now. We expected some of this
> fallout with the services split and plugin decomp (in fact, we counted on it
> to move this ball forward), and we had adopted these guideilnes:
> 
> 1. Other repos should not rely on oslo-incubated modules.
> (neutron/openstack/…)
> 2. Other repos should not rely on neutron’s test infrastructure.
> (neutron/tests/…)
> 3. For changes in any other area, they should be additive, or have a
> backwards compatibility shim or a big warning notice (the last being the
> suckiest answer.)
> 4. When we start getting “stable” interfaces in neutron/lib/…, which has the
> proviso of NO breaking changes without a shim or deprecation cycle, we get
> rid of restriction #3.
> 
> We’ve been regularly merging code that breaks #3 and we have plugins that use
> code from #1 and #2 today.
> 
> IMO, the core review team needs to be aware that neutron is now a library,
> and refactors and gratuitous cleanups have a pretty hefty cost. Especially
> in Liberty, be careful.
> 
> Thanks,
> doug
> 
> 
> 
> 
> 
> 
> 
> 
> --
> Kevin Benton
> __________________________________________________________________________
> 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
> 



More information about the OpenStack-dev mailing list