[openstack-dev] [openstack][nova] Streamlining of config options in nova

Jay Pipes jaypipes at gmail.com
Wed Aug 12 18:23:38 UTC 2015


On 08/12/2015 01:20 PM, Markus Zoeller wrote:
<snip>
> The three questions I have with every config option:
> 1) which service(s) access this option?
> 2) what does it do? / what's the impact?
> 3) which other options do I need to tweek to get the described impact?

All excellent questions that really should be answered in both the help 
string for the option as well as the documentation here:

http://docs.openstack.org/havana/config-reference/content/list-of-compute-config-options.html

Note that the above link is generated, IIRC, from the code, so 
increasing the details in option descriptions (help string) should show 
up there. Anne is that assumption correct?

> Would it make sense to stage the changes?
> M cycle: move the config options out of the modules to another place
>           (like the approach Sean proposed) and annotate them with
>           the services which uses them
> N cycle: inject the options into the drivers and eliminate the global
>           variables this way (like Daniel et al. proposed)

+1. I think the above is an excellent plan. You have my support.

Best,
-jay

> Especially for new contributors like me who didn't start in any of the
> early releases and didn't have the change to grow with Nova and its
> complexity, it would really help me a lot and enable me to contribute
> in a better way.
>
> As a side note:
> The "nova.flagmappings" file, which gets generated when you want to
> build the configuration reference manual, contains 804 config options
> for Nova. Quite a lot I think :)
>
> Sean Dague <sean at dague.net> wrote on 07/27/2015 04:35:56 PM:
>
>> From: Sean Dague <sean at dague.net>
>> To: openstack-dev at lists.openstack.org
>> Date: 07/27/2015 04:36 PM
>> Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config
>> options in nova
>>
>> On 07/27/2015 10:05 AM, Daniel P. Berrange wrote:
>>> On Fri, Jul 24, 2015 at 09:48:15AM +0100, Daniel P. Berrange wrote:
>>>> On Thu, Jul 23, 2015 at 05:55:36PM +0300, mhorban wrote:
>>>>> Hi all,
>>>>>
>>>>> During development process in nova I faced with an issue related
> with config
>>>>> options. Now we have lists of config options and registering options
> mixed
>>>>> with source code in regular files.
>>>>>  From one side it can be convenient: to have module-encapsulated
> config
>>>>> options. But problems appear when we need to use some config option
> in
>>>>> different modules/packages.
>>>>>
>>>>> If some option is registered in module X and module X imports module
> Y for
>>>>> some reasons...
>>>>> and in one day we need to import this option in module Y we will get
>>>>> exception
>>>>> NoSuchOptError on import_opt in module Y.
>>>>> Because of circular dependency.
>>>>> To resolve it we can move registering of this option in Y module(in
> the
>>>>> inappropriate place) or use other tricks.
>>>>>
>>>>> I offer to create file options.py in each package and move all
> package's
>>>>> config options and registration code there.
>>>>> Such approach allows us to import any option in any place of nova
> without
>>>>> problems.
>>>>>
>>>>> Implementations of this refactoring can be done piece by piece where
> piece
>>>>> is
>>>>> one package.
>>>>>
>>>>> What is your opinion about this idea?
>>>>
>>>> I tend to think that focusing on problems with dependancy ordering
> when
>>>> modules import each others config options is merely attacking a
> symptom
>>>> of the real root cause problem.
>>>>
>>>> The way we use config options is really entirely wrong. We have gone
>>>> to the trouble of creating (or trying to create) structured code with
>>>> isolated functional areas, files and object classes, and then we
> throw
>>>> in these config options which are essentially global variables which
> are
>>>> allowed to be accessed by any code anywhere. This destroys the
> isolation
>>>> of the various classes we've created, and means their behaviour often
>>>> based on side effects of config options from unrelated pieces of
> code.
>>>> It is total madness in terms of good design practices to have such
> use
>>>> of global variables.
>>>>
>>>> So IMHO, if we want to fix the real big problem with config options,
> we
>>>> need to be looking to solution where we stop using config options as
>>>> global variables. We should change our various classes so that the
>>>> neccessary configurable options as passed into object constructors
>>>> and/or methods as parameters.
>>>>
>>>> As an example in the libvirt driver.
>>>>
>>>> I would set it up so that /only/ the LibvirtDriver class in driver.py
>>>> was allowed to access the CONF config options. In its constructor it
>>>> would load all the various config options it needs, and either set
>>>> class attributes for them, or pass them into other methods it calls.
>>>> So in the driver.py, instead of calling
> CONF.libvirt.libvirt_migration_uri
>>>> everywhere in the code,  in the constructor we'd save that config
> param
>>>> value to an attribute 'self.mig_uri =
> CONF.libvirt.libvirt_migration_uri'
>>>> and then where needed, we'd just call "self.mig_uri".
>>>>
>>>> Now in the various other libvirt files, imagebackend.py, volume.py
>>>> vif.py, etc. None of those files would /ever/ access CONF.*. Any time
>>>> they needed a config parameter, it would be passed into their
> constructor
>>>> or method, by the LibvirtDriver or whatever invoked them.
>>>>
>>>> Getting rid of the global CONF object usage in all these files
> trivially
>>>> now solves the circular dependancy import problem, as well as
> improving
>>>> the overall structure and isolation of our code, freeing all these
> methods
>>>> from unexpected side-effects from global variables.
>>
>> How does that address config reload on SIGHUP? It seems like that
>> approach would break that feature.
>>
>>> Another significant downside of using CONF objects as global variables
>>> is that it is largely impossible to say which nova.conf setting is
>>> used by which service. Figuring out whether a setting affects
> nova-compute
>>> or nova-api or nova-conductor, or ... largely comes down to guesswork
> or
>>> reliance on tribal knowledge. It would make life significantly easier
> for
>>> both developers and administrators if we could clear this up and in
> fact
>>> have separate configuration files for each service, holding only the
>>> options that are relevant for that service.  Such a cleanup is not
> going
>>> to be practical though as long as we're using global variables for
> config
>>> as it requires control-flow analysis find out what affects what :-(
>>
>> Part of the idea that came up in the room is to annotate variables with
>> the service they were used in, and deny access to in services they are
>> not for.
>>
>>     -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>>
> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list