Open Stack

Propose it as a devref patch!

On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist <dustin at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160130/b11736b4/attachment.html>