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 <s...@dague.net> wrote on 07/27/2015 04:35:56 PM:
From: Sean Dague <s...@dague.net>
To: openstack-dev@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
