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.
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://
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://
installions instead of installations
I'm willing to help out with all of the issues!