[openstack-dev] [Neutron] Centralizing some config options will break many stadium projects
doug at doughellmann.com
Tue Nov 1 13:24:04 UTC 2016
Excerpts from Ihar Hrachyshka's message of 2016-11-01 13:13:41 +0100:
> Brandon Logan <brandon.logan at rackspace.com> wrote:
> > Hello Neutrinos,
> > 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.
> Definitely not neutron-lib material (unless carefully hidden behind clearly
> public API).
> There is a reason why oslo folks explicitly deny any support for
> configuration option names and locations their libraries expose .
> Options are for operators to change in configuration files, but not to
> access them or set programmatically. If there are options that subprojects
> need access to, we should expose them via explicitly public API, like we
> did with global_physnet_mtu .
+1 to creating a public API for managing the values instead of exposing
the options directly.
> > 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
> > later.
> > 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,
> > however.
> > 6) Any others I can't think of?
> Whatever makes subprojects stop accessing neutron configuration options
> programmatically. If we indeed identify something that plugins MUST have
> access to, then let’s work in scope of neutron-lib to expose those options
> through public API (not CONF object!)
> I believe it's subprojects who should identify and vouch for and propose
> neutron-lib patches to expose values they may need in their extensions;
> Neutron should of course give a notice about its plans; we could broadly
> target those changes to early Pike if we think it’s worth a postponement,
> and start talking to subprojects about them driving readiness for the
> changes during Ocata.
More information about the OpenStack-dev