[openstack-dev] [neutron] documenting configuration option segregation between services and agents

Dustin Lundquist dustin at null-ptr.net
Wed Jan 27 19:30:30 UTC 2016

We should expand services_and_agents devref to describe how and why
configuration options should be segregated between services and agents. I
stumbled into this recently while trying to remove a confusing duplicate
configuration option [1][2][3]. The present separation appears to be
'tribal knowledge', and not consistently enforced. So I'll take a shot at
explaining the status quo as I understand it and hopefully some seasoned
contributors can fill in the gaps.

Configuration Options

In addition to database access, configuration options are segregated
between neutron-server and agents. Both services and agents may load the
main neutron.conf since this file should contain the Oslo message
configuration for internal Neutron RPCs and may contain host specific
configuration such as file paths. In addition neutron.conf contains the
database, keystone and nova credentials and endpoints strictly for use by

In addition neutron-server may load a plugin specific configuration file,
yet the agents should not. As the plugin configuration is primarily site
wide options and the plugin provides the persistence layer for Neutron,
agents should instructed to act upon these values via RPC.

Each individual agent may have its own configuration file. This file should
be loaded after the main neutron.conf file, so the agent configuration
takes precedence. The agent specific configuration may contain
configurations which vary between hosts in a Neutron deployment such as the
external_network_bridge for a L3 agent. If any agent requires access to
additional external services beyond the Neutron RPC, those endpoints should
be defined in the agent specific configuration file (e.g. nova metadata for
metadata agent).


Disclaimers: this description is informed my by own experiences reading
existing documentation and examining example configurations including
various devstack deployments. I've tried to use RFC style wording: should,
may, etc.. I'm relatively confused on this subject, and my goal in writing
this is to obtain some clarity myself and share it with others in the form
of documentation.

[1] https://review.openstack.org/262621
[2] https://bugs.launchpad.net/neutron/+bug/1523614
[3] https://review.openstack.org/268153
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160127/d727f321/attachment.html>

More information about the OpenStack-dev mailing list