[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
brandon.logan at RACKSPACE.COM
Thu Oct 27 20:18:59 UTC 2016
I've come across an issue that I'd like to get input/opinions on. I've
been reviewing some of the centralize config options reviews and have
come across a few that would cause issues with other projects that are
importing these options, especially stadium projects. High level view
of the issue:
 would cause at least 22 projects to need to be fixed based on 
 would cause at least 12 projects to need to be fixed based on 
 looks to affect many other projects as well (I'm being lazy and
not counting them right now)
Initially, the thinking was that moving the config options around would
cause some breakage with projects outside of neutron, but that would be
fine because projects shouldn't really be using neutron as a library
and using it to register config options. However, with these 3
patches, I definitely don't feel comfortable breaking the amount of
projects these would break. It also makes me think that maybe these
options should be in neutron-lib since they're consumed so widely.
Anyway, I've come up with some possible options to deal with this, but
would like to hear others' opinions on this:
1) Let the patches merge and break those projects as a signal that
importing these shouldn't be done. The affected projects can choose to
push fixes that continue importing the neutron config options or
defining their own config options.
2) Deprecate the old locations for some timeframe, and then remove
3) Texas Three-Step: change the neutron patches to keep pointers in the
old locations to the new, and then push patches to the affected repos
with Depends-On directives. Once all patches merge, push up one more
patch to neutron to remove the old location.
4) Abandon these reviews and do nothing.
5) Move these config options to neutron-lib so that they can be used by
any project. This still requires doing one of the above options,
6) Any others I can't think of?
More information about the OpenStack-dev