Multiple instances of configuration directives

[Thomas Goirand]

Trove has multiple times the same configuration directives. For example, there is sql_connection on both trove.conf, trove-taskmanager.conf and trove-guestagent.conf. Instead, it would be nice to have them all use /etc/trove/trove.conf, so that it is configured only once. Then we would start for example taskmanager with:

trove-taskmanager --config-file=/etc/trove/trove.conf --config-file=/etc/trove/trove-taskmanager.conf

so that it would get the directives from both files (oslo supports that).

Doing what's above would simplify a lot both packaging (on my packages, many things are configured automatically with debconf, like keystone auth token, the sql_connection directive, and the RabbitMQ credentials) and configuration by our users.

[Denis M. (dmakogon)]

By telling "multiple times the same configuration directives" - could you please provide an example from codebase ?

[Li Ma (nick-ma-z)]

For simplicity, I think it can be solved by adding a note to trove.conf and suggest operators to specify database connection in that file, meanwhile the same configuration will be removed from other conf file.

In other way, I would like to suggest a blueprint to refactor the trove configuration files.

1. I just go through all the conf files in etc/trove and I find out most of configurations are the same but copied in different files, trove.conf, trove-conductor.conf, trove-guestagent.conf trove-taskmanager.conf. Here's the redundancy that can be dealt with. We don't need to specify the same keystone/database/message queue/log info... in all the trove conf files.

2. Instead, we can just have the global one configuration file: trove.conf and provide different sections for components.

3. Finally, we then introduce oslo-incubator/tools/config to automatic generate the configuration file trove.conf.

I'd appreciate any comments.

[Thomas Goirand (thomas-goirand)]

Hi, LGTM! :)

Your comments above is very much appreciated, this is exactly what needs to be done. Please go ahead!

I don't think you even need to write a blue print for this. Nearly all OpenStack services are doing this already, so you'd be only doing the same as everyone else, which is a very, very good thing. I would support and add a +1 on the code review, so please make sure to add me on the reviews.

Cheers,

Thomas

[Li Ma (nick-ma-z)]

Thanks for your comments, Thomas.

[Li Ma (nick-ma-z)]

Need to solve this bug first.

Some CLI options in group 'None' are parsed in the generator.

https://bugs.launchpad.net/oslo/+bug/1351845

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/112464

[OpenStack Infra (hudson-openstack)]

Change abandoned by Li Ma (<email address hidden>) on branch: master
Review: https://review.openstack.org/112464
Reason: re-submit it to openstack/requirements

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/113219

[OpenStack Infra (hudson-openstack)]

Change abandoned by Li Ma (<email address hidden>) on branch: master
Review: https://review.openstack.org/113219