This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 887822

Summary: a comprehensive quantum.conf file should be included
Product: Red Hat OpenStack Reporter: Nikola Dipanov <ndipanov>
Component: openstack-quantumAssignee: Bob Kukura <rkukura>
Status: CLOSED ERRATA QA Contact: Ofer Blaut <oblaut>
Severity: medium Docs Contact:
Priority: high    
Version: 1.0 (Essex)CC: apevec, dyocum, eglynn, jrd, lpeer, markmc, oblaut, zbitter
Target Milestone: snapshot2Keywords: Triaged
Target Release: 2.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-quantum-2012.2.1-6.el6ost Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 887334
: 905801 (view as bug list) Environment:
Last Closed: 2013-02-14 13:23:34 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 892339    

Description Nikola Dipanov 2012-12-17 07:14:15 EST
+++ 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
Comment 2 Alan Pevec 2012-12-18 09:26:59 EST
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.
Comment 3 jrd 2012-12-20 11:55:30 EST
Reopening this to make sure we're doing something sane with canned conf files.
Comment 4 Alan Pevec 2012-12-21 09:41:05 EST
see related bug 889485
Comment 5 Alan Pevec 2012-12-21 10:27:32 EST
*** Bug 889485 has been marked as a duplicate of this bug. ***
Comment 6 Alan Pevec 2013-01-11 11:11:21 EST
*** Bug 891311 has been marked as a duplicate of this bug. ***
Comment 7 Mark McLoughlin 2013-01-16 12:27:24 EST
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
Comment 8 Mark McLoughlin 2013-01-17 12:33:45 EST
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
      #
Comment 9 Bob Kukura 2013-01-17 12:35:04 EST
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?
Comment 10 Mark McLoughlin 2013-01-17 12:39:53 EST
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
Comment 11 Mark McLoughlin 2013-01-17 12:41:28 EST
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
Comment 12 Mark McLoughlin 2013-01-17 16:59:23 EST
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
Comment 13 Mark McLoughlin 2013-01-17 17:18:49 EST
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!
Comment 14 Mark McLoughlin 2013-01-17 17:25:21 EST
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"
Comment 15 Bob Kukura 2013-01-23 20:47:13 EST
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
Comment 16 Mark McLoughlin 2013-01-24 06:52:34 EST
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
Comment 17 Bob Kukura 2013-01-29 21:44:35 EST
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
Comment 18 Bob Kukura 2013-01-29 23:59:35 EST
Fixed package openstack-quantum-2012.2.1-6.el6ost is in brew.
Comment 19 Mark McLoughlin 2013-01-30 02:54:27 EST
bug #905801 filed on the keystone authtoken thing
Comment 21 Ofer Blaut 2013-02-07 05:57:10 EST
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
Comment 23 errata-xmlrpc 2013-02-14 13:23:34 EST
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