Propose it as a devref patch! On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist <dus...@null-ptr.net> wrote:
> 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. > > =====BEGIN PROPOSED DEVREF SECTION===== > 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 > neutron-server. > > 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). > > > ======END PROPOSED DEVREF SECTION====== > > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
