[Openstack-operators] OpenStack components and configuration options
mzoeller at de.ibm.com
Wed Jan 13 14:21:05 UTC 2016
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/
> >> config-options.html
> >> --
> >> Thanks,
> >> Matt Riedemann
> > Yepp, we're working on it in Nova. The current version can be found at
> > .
> > 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 .
> > References:
> >  http://docs.openstack.org/developer/nova/sample_config.html
> > 
> > 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
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
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)
More information about the OpenStack-operators