Excerpts from Ihar Hrachyshka's message of 2016-11-01 13:13:41 +0100: > Brandon Logan <brandon.lo...@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: > > > > [1] would cause at least 22 projects to need to be fixed based on [2] > > [3] would cause at least 12 projects to need to be fixed based on [4] > > > > [5] 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 [1]. > 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 [2].
+1 to creating a public API for managing the values instead of exposing the options directly. Doug > > [1] > http://docs.openstack.org/developer/oslo.config/faq.html#why-are-configuration-options-not-part-of-a-library-s-api > [2] > https://github.com/openstack/neutron/blob/181bdb374fc0c944b1168f27ac7b5cbb0ff0f3c3/neutron/plugins/common/utils.py#L43 > > > 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. > > Ihar > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev