Kevin Benton <[email protected]> wrote:
Propose it as a devref patch!
+1. Has it happened already?
On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist <[email protected]>
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Kevin Benton
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
