Open Stack

gilles.mocellin at nuagelibre.org wrote on 01/13/2016 02:39:56 PM:

> From: gilles.mocellin at nuagelibre.org
> To: openstack-operators at lists.openstack.org
> Date: 01/13/2016 02:42 PM
> Subject: Re: [Openstack-operators] OpenStack components and 
> configuration options
> 
> Le 2016-01-13 10:41, Markus Zoeller a écrit :
> >> On 1/12/2016 3:29 AM, gilles.mocellin at nuagelibre.org wrote:
> >> > Hello,
> >> > [...]
> >> >
> >> > So, is there a documentation where I could see :
> >> > - nova-api, reads theses configuration options
> >> > - nova-compute...
> > 
> >> Markus Zoeller is working on cleaning this up in Nova in Mitaka, see 
> >> the
> > 
> >> spec here:
> >> 
> >> 
> > http://specs.openstack.org/openstack/nova-specs/specs/mitaka/
> approved/centralize-
> >> config-options.html
> >> 
> >> --
> >> 
> >> Thanks,
> >> 
> >> Matt Riedemann
> > 
> > 
> > Yepp, we're working on it in Nova. The current version can be found at
> > [1].
> > The options [DEFAULT].vcpu_pin_set and 
> > [serial_console].serialproxy_port
> > are examples how the help will look like. Let me know if you find this
> > useful or if you miss something there.
> > It will still be one file "nova.conf" but our effort is a prerequisite
> > to the separated "nova-compute.conf", "nova-scheduler.conf" and so on.
> > The ongoing effort can be found at [2].
> > 
> > References:
> > [1] http://docs.openstack.org/developer/nova/sample_config.html
> > [2] 
https://review.openstack.org/#/q/topic:bp/centralize-config-options
> > 
> > Regards, Markus Zoeller (markus_z)
> 
> Yes, glad to see ther is some work about that.
> 
> If I understand, Tha conf sample is generated with headers comments like 

> :
> # From Nova.api
> ...
> # From Nova.compute
> 
> So what does theses headers mean ? Which component will use the config 
> options below ?
> # From Nova
> # From Nova.conf
> # From Nova.network
> # From nova.openstack.common.memorycache
> # From nova.virt
> ...
> 
> These seems to be related to libraries used, not a particular 
> component/service/process like nova-compute.
> 
> Comments like this is more clear :
> # Services which consume this:
> #
> # * nova-scheduler
> # * nova-compute

Yes, right, the headers where initally used to signalize which service
uses which config options (AFAIK) but this wasn't consistent. I want to
go to something like this:

    # From nova.conf
    # From oslo.log
    # From oslo.messaging
    # From oslo.policy
    # From oslo.service
    # From oslo.service
    # From oslo.db
    # From oslo.middleware
    # From oslo.concurrency
    # From keystonemiddleware.auth_token

Some of the options in the "/etc/nova/nova.conf" get passed through to
libs we utilize (for example "oslo.log"). These headers will give you
a clue which lib it is. Could be useful to know that in upgrade scenarios.

> An I see that it's what is shown as a "Positive Example" in the spec 
> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/
> centralize-config-options.html#quality-view.

Yepp, that's what we are heading to. We introduced a lot of options in
last cycles and it takes a bit time to make that easier to digest.

> Another positive point I can see, if we could separate config options in 

> specific config files for each service :
> - Packaging will be easier, especially install/remove/upgrades of one 
> service not interfering with others
> - Config management will also be easier, don't need to manage the 
> content of a file shared between several services
> 
> --
> gillesMo

That's not part of the current effort but when we are done it will
be a lot easier to achieve that.

Regards, Markus Zoeller (markus_z)