<div dir="ltr">Propose it as a devref patch!</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist <span dir="ltr"><<a href="mailto:dustin@null-ptr.net" target="_blank">dustin@null-ptr.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br><br></div><div>=====BEGIN PROPOSED DEVREF SECTION=====<br></div><div>Configuration Options<br>---------------------<br><br>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 neutron-server.<br><br></div><div>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.<br><br></div><div>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).<br><br><br>======END PROPOSED DEVREF SECTION======<br><br></div>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.<br><br></div><div><div><div><div><br>[1] <a href="https://review.openstack.org/262621" target="_blank">https://review.openstack.org/262621</a><br>[2] <a href="https://bugs.launchpad.net/neutron/+bug/1523614" target="_blank">https://bugs.launchpad.net/neutron/+bug/1523614</a><br>[3] <a href="https://review.openstack.org/268153" target="_blank">https://review.openstack.org/268153</a><br></div></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>