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

Kevin Benton blak111 at gmail.com
Wed Jul 1 19:45:49 UTC 2015


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?
 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150701/38339355/attachment.html>


More information about the OpenStack-dev mailing list