Open Stack

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

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.

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