Quantum plugin configuration needs clarified and corrected

Bug #1179046 reported by Joe T
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openstack-manuals
Fix Released
High
Matt Kassawara

Bug Description

Quantum plugins and agents share several of the same configuration files. Because of this, it's confusing to understand what configuration options are strictly for the plugin, strictly for the agent, or are shared between the two.

As an example:
http://docs.openstack.org/grizzly/openstack-network/admin/content/demo_routers_with_private_networks_installions.html

This page shows how /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini should be configured for 3 OpenStack roles (cloud controller / api server, network controller, and compute node). All but 1 configuration option is shared between the three. But even this is incorrect as the sql_connection no longer needs to be on two of the roles.

In most cases, specifying extraneous configuration options on roles that do not need those options poses no real error. However, when configuring Quantum with a configuration management system such as Puppet, where distinct roles (such as plugin and agent) are applied to distinct servers, a line must be drawn on what is distinct per role and what is shared. I have not been able to find a sole source of information which describes that.

A secondary minor issue is how the Ubuntu packages are named:

* python-quantum: contains all Quantum files including all plugins
* quantum-plugin-xxx: contains the ini file for a certain plugin
* quantum-plugin-xxx-agent: contains the agent daemon that should be run on agent roles but also pulls down the quantum-plugin-xxx package to resolve the ini file dependency.

Contrast this with RedHat which bundles all plugin-related files into a single package. For example openstack-quantum-openvswitch contains the quantum openvswitch python files, the ini file, and the daemon.

Joe T (joe-topjian-v)
description: updated
Tom Fifield (fifieldt)
Changed in openstack-manuals:
status: New → Confirmed
importance: Undecided → High
Tom Fifield (fifieldt)
tags: added: neutron
Anne Gentle (annegentle)
tags: added: quantum
Revision history for this message
Peter (ptter) wrote :

I agree and would like to help resolve this but I am unsure how to help.

It seems there is a lot of misinformation about the config files in general, as there are many versions around and it is not always clear to which host a config file applies and which configuration options are really needed for that specific service. The only way to know for sure is to look at the source code. And this is not something every user is able to do. The Security Guide and other official guides contain ambiguous information in a few examples.

Like you said, specifying extraneous configuration causes no problems but when using Puppet et al or even when you are trying to understand what is in the config file this creates a lot of confusion. Some people (like me) also like to run a "clean ship" and only want to add options that are really needed. Though, I would like to add that relying on default config options might create problems later on. What if the developers decide in Havana to change a default config option without you knowing? It could cause a lot of hair pulling :)

It would be great if every plugin, agent or service would have a CLI parameter where you could just dump a list of config options that it is going to use. I know some are already providing this via the logfile but some are not and I believe all config options are listed even if the particular plugin, agent or daemon isn't using them.

Also, adding more information on the config file examples would help too. I.e. You can already see this everywhere due to Havana (quantum -> neutron) where config files (or documentation examples) assume the service is already neutron instead of quantum with no mention of the version they are applying this too. It would be great to separate this and provide version information.

For instance:

http://docs.openstack.org/trunk/openstack-network/admin/content/metadata_agent_options.html

Lets say in Havana some options are dropped or added. If you would add an extra column with "version" or something like that you would be able to say "All", "Folsom", "Grizzly" or "Havana". This way the information stays current whichever version you are using. Just a thought.

BTW, the link http://docs.openstack.org/grizzly/openstack-network/admin/content/demo_routers_with_private_networks_installions.html seems to contains a typo:

installions instead of installations

I'm willing to help out with all of the issues!

Revision history for this message
Matt Kassawara (ionosphere80) wrote :

Joe,

Do any of these these issues still apply to the current version of the admin guide?

Revision history for this message
Joe T (joe-topjian-v) wrote :

Hi Matt,

I just did a full read of the Networking section in the Admin guide. In addition, I have been using various parts of it as reference for the past 3 months.

With regard to the plugin configuration documentation, I'm very humbled to say that this bug is closable. I should do a git blame on those sections and buy everyone listed a beer. :)

Thank you for touching base on this bug.

Joe

Revision history for this message
Matt Kassawara (ionosphere80) wrote :

Thanks, closing this bug!

Changed in openstack-manuals:
assignee: nobody → Matt Kassawara (ionosphere80)
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.