[openstack-dev] [Neutron] - breaking changes for plugins/drivers
harlowja at outlook.com
Thu Jul 2 01:29:03 UTC 2015
Doug Wiegley wrote:
>> On Jun 30, 2015, at 11:22 PM, Kevin Benton <blak111 at gmail.com
>> <mailto:blak111 at gmail.com>> wrote:
>> 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.
>> 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.
> 2. Other repos should not rely on neutron’s test infrastructure.
> 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.
http://docs.openstack.org/developer/debtcollector/ exists to help in #3
and #4 and hopefully it helps (whether people look at the warnings it
emit is another question entirely). It's used in oslo libraries (and
elsewhere, since it's made for all) for similar purposes...
> 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
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev