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

Doug Wiegley dougwig at parksidesoftware.com
Wed Jul 1 19:28:41 UTC 2015

> 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/ <https://review.openstack.org/#/c/196583/>
> 2. Removed the loopingcall common util with no deprecation cycle or announcement. https://review.openstack.org/#/c/192999/ <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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150701/4aa8bfe0/attachment.html>

More information about the OpenStack-dev mailing list