Open Stack

Excerpts from Brandon Logan's message of 2016-11-01 22:56:45 +0000:
> On Tue, 2016-11-01 at 13:13 +0100, Ihar Hrachyshka wrote:
> > 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]  
> > http://docs.openstack.org/developer/oslo.config/faq.html#why-are-conf
> > iguration-options-not-part-of-a-library-s-api
> > [2]  
> > https://github.com/openstack/neutron/blob/181bdb374fc0c944b1168f27ac7
> > b5cbb0ff0f3c3/neutron/plugins/common/utils.py#L43
> 
> Yeah allowing the options to be imported directly from code outside the
> repo doesn't make sense.  When you talk about a public API in neutron-
> lib for these options, are only talking about READ access as the
> example you gave? OR are you also talking about being able to register

We have seen patterns including an API for reading values and an API for
setting the defaults for values (useful for an application to override
the defaults set in a library).

> these options as well via functions that require no access to the
> options?  If that is the case, then these centralize config option

Options should be registered at runtime by the code that uses them. We
still have lots of code registering options when modules are imported,
but that's not the preferred way to do it because there are potentially
execution order issues when services start up. It's safe to register the
same option more than once, so doing it in some code that will use the
option is fine. For example, when constructing an instance of a class
that uses configuration options, the constructor can register the
options and then the other methods of the class know the options are
present and can be read.

> patches are basically doing that, except not in neutron-lib.  Do you
> think we should move these to neutron-lib instead?  This would mean the
> config options themselves would then probably end up living in neutron-
> lib (though I guess they wouldn't have to).  We'll still have to figure
> out what to do with the subprojects though, but having them in neutron-
> lib and neutron at the same time during a transition period might make
> this easier.

It could also lead to options being registered multiple times with
slightly different settings, which will throw errors. That just means
you need to make sure you don't change the help text or any other
attributions of the options while there are 2 copies.

> 
> > 
> > > 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.
> 
> Makes sense.
> 
> > 
> > Ihar
> > 
> > _____________________________________________________________________
> > _____
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev