On 2016/02/08 18:17, Ihar Hrachyshka wrote:
Kevin Benton <blak...@gmail.com> wrote:
Propose it as a devref patch!
+1. Has it happened already?
Here https://review.openstack.org/#/c/275381/
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
__________________________________________________________________________
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
__________________________________________________________________________
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