[openstack-dev] [neutron] documenting configuration option segregation between services and agents
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
Re: [openstack-dev] [neutron] documenting configuration option segregation between services and agents
Propose it as a devref patch! On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist 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
Re: [openstack-dev] [neutron] documenting configuration option segregation between services and agents
Kevin Benton wrote: Propose it as a devref patch! +1. Has it happened already? On Wed, Jan 27, 2016 at 12:30 PM, Dustin Lundquist 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
Re: [openstack-dev] [neutron] documenting configuration option segregation between services and agents
On 2016/02/08 18:17, Ihar Hrachyshka wrote: Kevin Benton 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 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
