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

Markus Zoeller mzoeller at de.ibm.com
Mon Aug 17 07:37:09 UTC 2015


Michael Still <mikal at stillhq.com> wrote on 08/12/2015 10:08:26 PM:

> From: Michael Still <mikal at stillhq.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 08/12/2015 10:14 PM
> Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config 
> options in nova
> [...]
> 
> Do we see https://review.openstack.org/#/c/205154/ as a reasonable 
> example of such centralization? If not, what needs to change there to 
> make it an example of that centralization? I see value in having a 
> worked example people can follow before we attempt a large number of 
> these moves.
> [...]
> Michael

IIUC, this change doesn't yet meet the idea and needs to change by:
* creating a module "nova/conf/default.py" and
* move the imagecache config options to that module

After this change, it wouldn't address the need to lookup which
services use a specific config option. What about enhancing this to
something like this:

Add a "services" package to the tree structure, which would then look
like this:

    ├── nova
    │   ├── conf
    │   │   ├── sections
    │   │   │   ├── default.py
    │   │   └── services
    │   │       ├── compute.py

The *registration* of the config options would be done by sections
(here: "default.py"):

    from oslo_config import cfg
    CONF = cfg.CONF
    imagecache_opts = [
        cfg.IntOpt('image_cache_manager_interval',
                   default=2400,
                   help='... help text ...'),
        # [...]
        ]
    CONF.register_opts(imagecache_opts)

The *import* of the options would be done by service
(here: "compute.py"):

    from oslo_config import cfg
    CONF = cfg.CONF
    CONF.import_opt('image_cache_manager_interval', 
                    'nova.conf.sections.default')
    # ... more here ...

The usage via the "conf.service.compute" module
(here: "imagecache.py"):

    import nova.conf.services.compute as cpu

    def __init__(self):
        self.remove_unused_base_images = \
            cpu.CONF.remove_unused_base_images


Which means we would still use global variables but would at least know
which services are meant to use them and which module thinks to which
service it belongs (by using its config variables). An additional
checking if a module uses "import_opt" could result in a warning and
when the restructuring is done, result in an error.

I think we wouldn't have problems with cyclic dependencies this way.

The generation of the sample.conf file must be changed to use the
"nova.conf.sections" package instead of the "opts.list_opts" methods
as soon as we are done.

Scenarios: 
1) A new option should be added:
    => register in "conf.sections.<section>.py"
    => import in "conf.services.<service>.py"
    + It's immediatley clear which service is affected by that
    + If someone has to import another "conf.services.<service>.py"
      than the already existing ones, it's immediately clear in the
      review.
    + The person who adds it, sees that we have already a lot of config
      options and maybe is a bit more hesitant (let me dream, ...).
2) The "config.sample" has to be generated
    => use "conf.sections.*.py" for the generation
3) Someone wants a "nova.conf" for a compute node
    => use "conf.services.compute.py" for the generation
4) An existing option should be accessible by another service
    => import it in "conf.services.<another-service>.py"

Regards,
Markus Zoeller (markus_z)



More information about the OpenStack-dev mailing list