[openstack-dev] [neutron] documenting configuration option segregation between services and agents

Hirofumi Ichihara ichihara.hirofumi at lab.ntt.co.jp
Tue Feb 9 02:27:40 UTC 2016


On 2016/02/08 18:17, Ihar Hrachyshka wrote:
> Kevin Benton <blak111 at 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 
>> <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
>> __________________________________________________________________________ 
>>
>> 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
>
>
> __________________________________________________________________________ 
>
> 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
>
>






More information about the OpenStack-dev mailing list