Open Stack

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:
> >
> > [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
>