+++ This bug was initially created as a clone of Bug #887334 +++ Description of problem: A .conf file with a comprehensive set of configuration options should be shipped various nova services. Here is a good example to work from: https://github.com/yocum137/nova.conf/blob/master/nova.conf --- Additional comment from Dan Yocum on 2012-12-14 12:22:34 EST --- This one looks like it's more up-to-date: https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample
Unlike Nova, Quantum RPM is not shipping own copy of quantum.conf, it edits https://github.com/openstack/quantum/blob/master/etc/quantum.conf so doc comments are preserved.
Reopening this to make sure we're doing something sane with canned conf files.
see related bug 889485
*** Bug 889485 has been marked as a duplicate of this bug. ***
*** Bug 891311 has been marked as a duplicate of this bug. ***
See bug #887804 for conclusions we came to for Cinder Quantum is different in a number of respects: - quantum-server is run with quantum.conf and plugin.ini. Can we just stop loading plugin.ini? If we kept it around for backwards compat, it might be past its usefulness at this point? - like glance, upstream quantum.conf contains a number of uncommented values so we need to know if any of those differ from the defaults specified in the code These values seem to be a fairly arbitrary choice: verbose = True These values are essential for Quantum to operate AFAIR: notification_driver = quantum.openstack.common.notifier.list_notifier list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier This is our only true distribution default AFAICT: auth_strategy = noauth That all means: 1) Take our distrbution defaults above (i.e. auth_strategy, notification_driver, etc.) and put them in /usr/share/quantum/quantum-dist.conf The systemd units and init scripts will need to be updated to do: --config-file=/usr/share/quantum/quantum-dist.conf --config-file=/etc/quantum/quantum.conf This means that users can start with an empty /etc/quantum/quantum.conf file and still be using the distribution defaults This file should not be marked as %config(noreplace) since it is not intended to be user-editable 2-4) Take upstream quantum and install it in /etc/quantum We should uncomment any of the default values in there and make sure the commented out defaults match the distribution defaults This means the default user-editable config file contains nothing but comments explaining what options are available 5) In the productized packages, we should strip the sample quantum.conf to only include options we recommend using and perhaps improve the descriptions. 6) In our default /etc/quantum/quantum.conf we should also document the [keystone_authtoken] section and put the keystone_authtoken defaults in /usr/share/quantum/quantum-dist.conf I think we should apply similar principles to the other config files like dhcp_agent.ini (e.g. move the defaults to /usr/share/quantum/dhcp_agent-dist.ini) but sorting out quantum.conf is the first priority
The idea with plugin.ini is that the user should symlink e.g. /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini to /etc/quantum/plugin.ini I think we should aim for all conf files under /etc/quantum/plugins to be empty apart from comments - defaults should go in /usr/share/quantum Looking at the ovs and linuxbridge defaults, that's easy to achieve: [DATABASE] sql_connection = sqlite:// reconnect_interval = 2 [AGENT] polling_interval = 2 root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf those can just go into /usr/share/quantum/quantum-dist.conf Summary: - /etc/quantum/plugins conf files should only contain comments - /etc/quantum/quantum.conf should also just contain comments - /usr/share/quantum/quantum-dist.conf would contain: [DEFAULT] verbose = True notification_driver = quantum.openstack.common.notifier.list_notifier list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier auth_strategy = noauth [DATABASE] sql_connection = sqlite:// reconnect_interval = 2 [AGENT] polling_interval = 2 root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf - the service should be launched with: --config-file=/usr/share/quantum/quantum-dist.conf --config-file=/etc/quantum/quantum.conf --config-file=/etc/quantum/plugin.ini - we should probably also ship a plugin.ini file containing something like # # This file should contain plugin specific configuration # First choose a plugin by setting the core_plugin option # in quantum.conf and then symlink the appropriate sample # plugin configuration in place of this file e.g. # # ln -s /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini /etc/quantum/plugin.ini #
The /etc/quantum/plugin.ini file is a symlink to the /etc/quantum/plugins/<plugin>/<something-plugin-specific>.ini file, which contains config variable specific to the plugin being used. This symlink is created by the quantum-server-setup script based on the selected plugin. Nothing in the upstream code should require the plugin-specific configuration to be obtained from a separate file. It would be possible to roll everything for all plugins into /etc/quantum/quantum.conf and/or /usr/share/quantum/quantum-dist.conf. Do we want to merge them or keep plugin-specific configuration in separate files? If we do not merge the plugin configuration files into quantum.conf and/or quantum-dist.conf, then it seems we'd need to apply the same pattern to the plugin configuration files. This would involve quantum-server-setup creating /etc/quantum/plugin-dist.ini as a symlink to /usr/share/quantum/plugins/<plugin>/<something-plugin-specific>-dist.ini, and then running quantum-server with: --config-file=/usr/share/quantum/quantum-dist.conf --config-file=/etc/quantum/plugin-dist.ini --config-file=/etc/quantum/quantum.conf --config-file=/etc/quantum/plugin.ini The init scripts for the L2 agents don't use the symlink(s), since each is specific to the plugin it supports, so these would be run with: --config-file=/usr/share/quantum/quantum-dist.conf --config-file=/usr/share/quantum/plugins/<plugin>/<something-plugin-specific>-dist.ini --config-file=/etc/quantum/quantum.conf --config-file=/etc/quantum/plugins/<plugin>/<something-plugin-specifiy>.ini The DHCP and L2 agents don't use the plugin-specific configuration files (although they have some variables that need to be set based on the chosen plugin), so they would be run with: ---config-file /usr/share/quantum/quantum-dist.conf --config-file /usr/share/quantum/[dhcp|l3]_agent-dist.ini -config-file /etc/quantum/quantum.conf --config-file /etc/quantum/[dhcp|l3]_agent.ini This is starting to seem kind of complex. Is this what we want?
The basic principle here is "defaults should be separate from user configuration" Two reasons I can think of for this: - it's really nice if a user or management tool can start with a blank user config file, set the values they care about and get the right defaults for those things they don't cate about. Right now, We force them to start with our default config files and edit them. How can they easily get back to the original defaults if they change their config and decide they want to start over? - if we change a default in a newer version, we want to be sure that users who don't care about the value of this option (i.e. they haven't chosen a value for it) get the new default. Changing defaults may sound like a potential incompatible change, but think of things like timeouts. - also consider where we add a new option and we specify its default in something like /etc/quantum/quantum.conf. If a user has previously edited their quantum.conf, they won't get the correct default value for the new option after an rpm update
for the record, I think our comments are overlapping ... i.e. comment #8 and #10 are follow ups to #comment 7 and #comment #9 is a reply to #comment 7
By the way, I'm deliberately ignoring the existence of the quantum-server-setup script - we should aim for it to be straightforward to configure quantum without using the script I agree that we don't want the /etc/quantum/plugin-dist.ini complexity you describe above - at least for ovs and linuxbridge though, the defaults can just go in quantum-dist.conf Looking at the dhcp agent, I think you'd just need a dhcp_agent-dist.ini file containing: [DEFAULT] interface_driver = quantum.agent.linux.interface.OVSInterfaceDriver root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf The defaults in the config file for state_path (/var/lib/quantum) and dhcp_driver (quantum.agent.linux.dhcp.Dnsmasq) mirror the defaults in the code, so they don't need to be repeated in the -dist file I've already suggested the root_helper default could go in quantum-dist.conf, so if we put interface_driver in quantum-dist.conf too then there's no need for dhcp_agent-dist.ini And on an "all in one config file" - I don't love the idea of per-plugin config files so I'm all in favour of trying this approach. It would certainly greatly simplify things for users The l3 agent defaults are again interface_driver and root_helper ... so, that's good cause for them to just go into quantum-dist.conf The other l3 agent defaults are: [DEFAULT] auth_url = http://localhost:35357/v2.0 auth_region = RegionOne admin_tenant_name = %SERVICE_TENANT_NAME% admin_user = %SERVICE_USER% admin_password = %SERVICE_PASSWORD% That all looks reasonable to put into quantum-dist.conf too
I think I need to summarize yet again, this time with the "single config file" approach: - Add a quantum-dist.conf file containing [DEFAULT] # we like INFO messages verbose = True # required for the dhcp agent's 'rpc' - note notification_driver = quantum.openstack.common.notifier.list_notifier list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier rpc_backend = nova.openstack.common.rpc.impl_qpid # don't assume keystone; same as nova's default auth_strategy = noauth # default to rootwrap root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf # FIXME: explain me auth_url = http://localhost:35357/v2.0 auth_region = RegionOne admin_tenant_name = %SERVICE_TENANT_NAME% admin_user = %SERVICE_USER% admin_password = %SERVICE_PASSWORD% [DATABASE] sql_connection = sqlite:// reconnect_interval = 2 [AGENT] polling_interval = 2 root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf - Make /etc/quantum/quantum.conf a file just containing comments explaining the available options. The upstream quantum.conf with the default values commented out updated to reflect the distribution defaults is a good starting point. Good enough for Fedora/EPEL to be sure. - Install etc/quantum/plugins/*/*.ini into /usr/share/doc, make them just contain comments and add some documentation in quantum.conf about how to use those sample config files to configure the chosen plugin in quantum.conf - Do away with the notion of plugin.ini as a symlink; remove the --config-file for it from the quantum-server init script - Also do away with linuxbridge-agent and openvswitch-agent loading a config file from /etc/quantum/plugins/ - Similarly, it looks like we don't need l3_agent.ini or dhcp_agent.ini, but the documentation from the upstream samples should go in quantum.conf - Don't forget the [keystone_authtoken] ... that should also go in quantum.conf and its defaults in quantum-dist.conf Phew, I hope that's everything!
From apevec - "One thing to verify is Nova selinux policy: /etc/nova/nova.conf is etc_t while files under /usr/share/nova/ get usr_t"
Mark, Although I like the idea of reducing the complexity by combining configuration files, and Mark's proposal seems workable, I'm concerned eliminating the separate .ini files for the plugins and agents will confuse users familiar with the upstream code and/or documentation, and break compatibility with puppet modules, and the like, that expect the upstream config file layout. It also seems odd to include configuration for all the plugins in quantum.conf and quantum-dist.conf when those plugins are packaged in separate RPMs that may not be installed. We may not need separate *-dist.ini files, but I'm leaning towards keeping the *.ini files and the plugin.ini symlink. I could be convinced otherwise, though. -Bob
In comment #9 you seemed up for getting rid of the per-plugin ini files. If you think that's too bit a change at this point in 2.1, fair enough Updating the summary for that: - Add a quantum-dist.conf file containing [DEFAULT] # we like INFO messages verbose = True # required for the dhcp agent's 'rpc' - note notification_driver = quantum.openstack.common.notifier.list_notifier list_notifier_drivers = quantum.openstack.common.notifier.rabbit_notifier rpc_backend = nova.openstack.common.rpc.impl_qpid # don't assume keystone; same as nova's default auth_strategy = noauth # default to rootwrap root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf # FIXME: explain me auth_url = http://localhost:35357/v2.0 auth_region = RegionOne admin_tenant_name = %SERVICE_TENANT_NAME% admin_user = %SERVICE_USER% admin_password = %SERVICE_PASSWORD% [DATABASE] sql_connection = sqlite:// reconnect_interval = 2 [AGENT] polling_interval = 2 root_helper = sudo quantum-rootwrap /etc/quantum/rootwrap.conf - Make quantum.conf, dhcp_agent.ini, l3_agent.ini and plugs/*/*.ini files containing only comments explaining the available options. The upstream config files with the default values commented out and updated to reflect the distribution defaults is a good starting point. Good enough for Fedora/EPEL to be sure. - Keep etc/quantum/plugins/*/*.ini and add a default plugin.ini file which says something like: # # This file should contain plugin specific configuration # First choose a plugin by setting the core_plugin option # in quantum.conf and then symlink the appropriate sample # plugin configuration in place of this file e.g. # # ln -s /etc/quantum/plugins/linuxbridge/linuxbridge_conf.ini /etc/quantum/plugin.ini # - All of the initscripts need a --config-file argument to load quantum-dist.conf before quantum.conf - In the productized packages, we should strip the sample quantum.conf to only include options we recommend using and perhaps improve the descriptions. - Don't forget the [keystone_authtoken] ... that should also go in quantum.conf and its defaults in quantum-dist.conf
Mark, I'm not sure about the [keystone_authtoken] config you refer to. I don't see that used in the quantum source, except the l3_agent config above that does not use that config section. -Bob
Fixed package openstack-quantum-2012.2.1-6.el6ost is in brew.
bug #905801 filed on the keystone authtoken thing
RPM does include conf files [root@intg-vdsb ~(keystone_admin)]$ rpm -ql openstack-quantum-2012.2.1-6.el6ost.noarch | grep conf /etc/quantum/quantum.conf /etc/quantum/rootwrap.conf /usr/share/quantum/quantum-dist.conf rpm -ql openstack-quantum-2012.2.1-6.el6ost.noarch | grep .ini /etc/quantum/api-paste.ini /etc/quantum/dhcp_agent.ini /etc/quantum/l3_agent.ini /etc/quantum/plugin.ini With the info about
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0260.html