Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 05/03/2014 12:48 AM, Mark T. Voelker wrote: I think it's not just devstack/grenade that would benefit from this. Variance in the plugin configuration patterns is a fairly common complaint I hear from folks deploying OpenStack, and going to a single config would likely make that easier. I think it probably benefits distributions too. There have been several issues with distro init scripts not properly supplying all the necessary --config-file arguments to Neutron services because they're not uniformly pattered. With my OpenStack Debian package maintainer hat on... TL;DR: Moving to a single configuration file is unimportant for me, what I would like is configuration files that I can easily parse. Longer version: The issue hasn't been multiple configuration. I've dealt with that by parsing the core_plugin value, and do what should be done in the init script depending on that. The main issue with current configuration files is that they are *not* parser friendly. Eg, there stuff like: # Example: # directive = value #directive=None A script cannot make the difference between the first and the 2nd instance of the directive, and it's like this all over the place in Neutron configuration files. Something like this: sed -i s/[ \t#]*directive[ \t]*=.*/directive = newvalue/ \ /etc/neutron/neutron.conf which I extensively use (well, it's a little bit more complicated as what I do doesn't show in /proc: for security purposes, directives values shouldn't show in a ps, but you got the point...). Even worse, there's some huge example snippet which I had to delete (for the same parseability reasons). These belong in the openstack-manuals, or in the sphinx doc, *not* in a configuration files. So for me, parseability should be addressed with top priority. I am currently patching the neutron configuration files because of this, and I have to constantly rebase my debian-specific patches, that's boring, and error prone. I'd very much prefer generated configuration files like for other projects instead (on a single or multiple configuration files: I don't care since I have the logic already implemented...). Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 05/04/2014 01:13 PM, John Dickinson wrote: To add some color, Swift supports both single conf files and conf.d directory-based configs. See http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration. +1 The single config file pattern is quite useful for simpler configurations, but the directory-based ones becomes especially useful when looking at cluster configuration management tools--stuff that auto-generates and composes config settings (ie non hand-curated configs). For example, the conf.d configs can support each middleware config or background daemon process in a separate file. Or server settings in one file and common logging settings in another. Also +1 (Also, to answer before it's asked [but I don't want to derail the current thread], I'd be happy to look at oslo config parsing if it supports the same functionality.) And a final +1. :) -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On Mon, May 5, 2014 at 10:18 AM, Jay Pipes jaypi...@gmail.com wrote: On 05/04/2014 01:13 PM, John Dickinson wrote: To add some color, Swift supports both single conf files and conf.d directory-based configs. See http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration. +1 The single config file pattern is quite useful for simpler configurations, but the directory-based ones becomes especially useful when looking at cluster configuration management tools--stuff that auto-generates and composes config settings (ie non hand-curated configs). For example, the conf.d configs can support each middleware config or background daemon process in a separate file. Or server settings in one file and common logging settings in another. Also +1 (Also, to answer before it's asked [but I don't want to derail the current thread], I'd be happy to look at oslo config parsing if it supports the same functionality.) And a final +1. :) oslo.config includes a --config-dir option for this. When --config-dir dirname is used with an app, oslo.config parses dirname/*.conf and adds the settings to the configuration being built. Doug -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 05/03/2014 03:53 PM, gustavo panizzo gfa wrote: On 05/02/2014 11:09 AM, Mark McClain wrote: To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? i like this idea, it makes easy to use configuration manager to setup neutron, also it fits perfectly with real life where sometimes you need more than one l3 agent running on the same box Question (because I honestly don't know), when would you want more than 1 l3 agent running on the same box? -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On May 4, 2014, at 8:08, Sean Dague s...@dague.net wrote: Question (because I honestly don't know), when would you want more than 1 l3 agent running on the same box? For the legacy case where there are multiple external networks connected to a node on different bridges. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
If the consensus is to unify all the config options into a single configuration file, I'd suggest following what the Nova folks did with [1], which I think is what Salvatore was also hinted. This will also help mitigate needless source code conflicts that would inevitably arise when merging competing changes to the same file. I personally do not like having a single file with gazillion options (the same way I hate source files with gazillion LOC's but I digress ;), but I don't like a proliferation of config files either. So I think what Mark suggested below makes sense. Cheers, Armando [1] - https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt On 2 May 2014 07:09, Mark McClain mmccl...@yahoo-inc.com wrote: On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? mark [1] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/ [2] http://packages.ubuntu.com/search?keywords=neutronsearchon=namessuite=trustysection=all [3] https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2 [4]https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
To add some color, Swift supports both single conf files and conf.d directory-based configs. See http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration. The single config file pattern is quite useful for simpler configurations, but the directory-based ones becomes especially useful when looking at cluster configuration management tools--stuff that auto-generates and composes config settings (ie non hand-curated configs). For example, the conf.d configs can support each middleware config or background daemon process in a separate file. Or server settings in one file and common logging settings in another. (Also, to answer before it's asked [but I don't want to derail the current thread], I'd be happy to look at oslo config parsing if it supports the same functionality.) --John On May 4, 2014, at 9:49 AM, Armando M. arma...@gmail.com wrote: If the consensus is to unify all the config options into a single configuration file, I'd suggest following what the Nova folks did with [1], which I think is what Salvatore was also hinted. This will also help mitigate needless source code conflicts that would inevitably arise when merging competing changes to the same file. I personally do not like having a single file with gazillion options (the same way I hate source files with gazillion LOC's but I digress ;), but I don't like a proliferation of config files either. So I think what Mark suggested below makes sense. Cheers, Armando [1] - https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt On 2 May 2014 07:09, Mark McClain mmccl...@yahoo-inc.com wrote: On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? mark [1] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/ [2]
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
I second the conf.d model. Regards, Mandeep On Sun, May 4, 2014 at 10:13 AM, John Dickinson m...@not.mn wrote: To add some color, Swift supports both single conf files and conf.d directory-based configs. See http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration . The single config file pattern is quite useful for simpler configurations, but the directory-based ones becomes especially useful when looking at cluster configuration management tools--stuff that auto-generates and composes config settings (ie non hand-curated configs). For example, the conf.d configs can support each middleware config or background daemon process in a separate file. Or server settings in one file and common logging settings in another. (Also, to answer before it's asked [but I don't want to derail the current thread], I'd be happy to look at oslo config parsing if it supports the same functionality.) --John On May 4, 2014, at 9:49 AM, Armando M. arma...@gmail.com wrote: If the consensus is to unify all the config options into a single configuration file, I'd suggest following what the Nova folks did with [1], which I think is what Salvatore was also hinted. This will also help mitigate needless source code conflicts that would inevitably arise when merging competing changes to the same file. I personally do not like having a single file with gazillion options (the same way I hate source files with gazillion LOC's but I digress ;), but I don't like a proliferation of config files either. So I think what Mark suggested below makes sense. Cheers, Armando [1] - https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt On 2 May 2014 07:09, Mark McClain mmccl...@yahoo-inc.com wrote: On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 05/04/2014 01:22 PM, Mark McClain wrote: On May 4, 2014, at 8:08, Sean Dague s...@dague.net wrote: Question (because I honestly don't know), when would you want more than 1 l3 agent running on the same box? For the legacy case where there are multiple external networks connected to a node on different bridges. legacy since when? i'm still using it on icehouse pls, let us know if there is something better! thanks! -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
External networks can be handled just like regular networks by not specifying the external bridge. They will then be tagged with the provider network information just like any other tenant network. On Sun, May 4, 2014 at 6:52 PM, gustavo panizzo gfa g...@zumbi.com.arwrote: On 05/04/2014 01:22 PM, Mark McClain wrote: On May 4, 2014, at 8:08, Sean Dague s...@dague.net wrote: Question (because I honestly don't know), when would you want more than 1 l3 agent running on the same box? For the legacy case where there are multiple external networks connected to a node on different bridges. legacy since when? i'm still using it on icehouse pls, let us know if there is something better! thanks! -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 02/05/14 22:09, Mark McClain wrote: On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? What do operators want? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On Fri, May 02, 2014 at 08:18:18AM -0500, Kyle Mestery wrote: On Fri, May 2, 2014 at 6:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. Is there an overview somewhere to explain this design point? All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. I think this is entirely possible. Each plugin has it's own configuration, and this is usually done in it's own section. In reality, it's not necessary to have more than a single config file, as long as the sections in the configuration file are unique. FWIW, I think this would definitely be useful - to have a Neutron single config file with unique sections. I frequently try to test two-node OpenStack setups with Neutron, where I need to keep track of at-least these config files (correct me if I'm doing something ineffeciently) for Neutron alone. Controller node --- 1. /etc/neutron/neutron.conf 2. /etc/neutron/plugin.ini 3. /etc/neutron/dhcp_agent.ini 4. /etc/neutron/l3_agent.ini - I notice dhcp_agent and l3_agent configs similar most of the time 5. /etc/neutron/dnsmasq.conf - I use this, so that I can log dnsmasq details to a file instead of journalctl) 6. /etc/neutron/metadata_agent.ini 7. /etc/neutron/api-paste.ini - This is auto-generated I believe Compute node 1. /etc/neutron/neutron.conf 2. /etc/neutron/plugin.ini 3. /etc/neutron/metadata_agent.ini Not considering iptables/firewalld configs. -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On 05/02/2014 11:09 AM, Mark McClain wrote: To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? i like this idea, it makes easy to use configuration manager to setup neutron, also it fits perfectly with real life where sometimes you need more than one l3 agent running on the same box -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] explanations on the current state of config file handling
Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. Is there an overview somewhere to explain this design point? All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On Fri, May 2, 2014 at 6:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. Is there an overview somewhere to explain this design point? All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. I think this is entirely possible. Each plugin has it's own configuration, and this is usually done in it's own section. In reality, it's not necessary to have more than a single config file, as long as the sections in the configuration file are unique. I'd like to hear from other Neutron developers on this as well. We could propose this change for Juno to migrate to a single config file if everyone agrees. Thanks, Kyle -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
On May 2, 2014, at 7:39 AM, Sean Dague s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited. One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2]. We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file. This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script. I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2. Is there an overview somewhere to explain this design point? Sadly no. It’s a historical convention that needs to be reconsidered. All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. +1 to evolving into a more limited set of files. The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more. In some cases, the files share a set of common options and in other cases there are divergent options [3][4]. Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone. To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files. Neutron Servers/Network Nodes /etc/neutron.d neutron.conf (Common Options) server.d (all plugin/service config files ) service.d (all service config files) Hypervisor Agents /etc/neutron neutron.conf agent.d (Individual agent config files) The invocations would then be static: neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d Service Agents: neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d Hypervisors (assuming the consolidates L2 is finished this cycle): neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d Thoughts? mark [1] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/ [2] http://packages.ubuntu.com/search?keywords=neutronsearchon=namessuite=trustysection=all [3] https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2 [4]https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] explanations on the current state of config file handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 for making single config the norm I think it's not just devstack/grenade that would benefit from this. Variance in the plugin configuration patterns is a fairly common complaint I hear from folks deploying OpenStack, and going to a single config would likely make that easier. I think it probably benefits distributions too. There have been several issues with distro init scripts not properly supplying all the necessary --config-file arguments to Neutron services because they're not uniformly pattered. Many distros take their cues from the sample config files (e.g. https://github.com/openstack/neutron/tree/master/etc/ ), so ideally we could unify things there early in the Juno cycle to give packagers time to adapt. The config management tool communities on StackForge (Puppet/Chef/etc) would likely also benefit from greater uniformity as well. At Your Service, Mark T. Voelker On 05/02/2014 11:24 AM, Salvatore Orlando wrote: Technically we don't need anything in neutron to migrate to a single config files if not rearrange files in ./etc For devstack, iniset calls to plugin-specific configuration files should then be adjusted accordingly. I think we started with plugin specific configuration files because at that time it looked better to keep common arguments separated from the plugin-specific ones. From what I gather this could and should be achieved together with the config file generation work. I recall having seen somebody (don't remember who) volunteer for that on IRC. Salvatore On 2 May 2014 15:18, Kyle Mestery mest...@noironetworks.com mailto:mest...@noironetworks.com wrote: On Fri, May 2, 2014 at 6:39 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: Some non insignificant number of devstack changes related to neutron seem to be neutron plugins having to do all kinds of manipulation of extra config files. The grenade upgrade issue in neutron was because of some placement change on config files. Neutron seems to have *a ton* of config files and is extremely sensitive to their locations/naming, which also seems like it ends up in flux. Is there an overview somewhere to explain this design point? All the other services have a single config config file designation on startup, but neutron services seem to need a bunch of config files correct on the cli to function (see this process list from recent grenade run - http://paste.openstack.org/show/78430/ note you will have to horiz scroll for some of the neutron services). Mostly it would be good to understand this design point, and if it could be evolved back to the OpenStack norm of a single config file for the services. I think this is entirely possible. Each plugin has it's own configuration, and this is usually done in it's own section. In reality, it's not necessary to have more than a single config file, as long as the sections in the configuration file are unique. I'd like to hear from other Neutron developers on this as well. We could propose this change for Juno to migrate to a single config file if everyone agrees. Thanks, Kyle -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY8xWAAoJELUJLUWGN7CbGyIQAMZq6zDu9wvYRIJgafgRY3MK TR1cGqlljchEzSCHw6kF7/s6JdlVbRruBHELPmIUpvStDlyc4gUdVNatqq/cbn2S Kp0LwXcZ+kATTKP0AgzpjYWJawwuVGvlXvmgMMvSkG7sJ2U6RIhjDLLjBkAFBulN bT+KRhfPjFjicW1UdAvQbT5xNkXk7pU1/+Uvo5v776CTeDkJ2VUVtDP9SpOMAKmv i+ykOmKrpIaw634ThvVE7dYkg4TKf4xacnM0GO+HTJ98uKSK4VOIwGTCg7QAM5/p QCc/Uy8LttKsc5NtTyCfU/37zOp3n0PynS3avNMioTk7Z78Xw5oQ131BAj5A4YrE H+Kto8OThjRSApdSnAY6kUvO2+6UGCdiIKq/HsicbCHB4DzNtduyMap9Bm0DtJz5 /f6BmKhDNXIdtK3wks0YPMH43dUWcvL529IFO7pBOqucTCA91Pyji3FXPUN/IoDV v7tpbtMuDkyV+0fmY1GDj0jT8qVdcOnkiirHZPujtvC6PrwpMPWKui1iAwqUFZxh Og1iAMYwBm/rBn+3xg3tgn9zJJ1/W+HwROdUbhYOo8yg7l4Oc1wRMM68U+5HC6Iw 01VMs7fiH9qVd/3OgF8IHL/zgiKIFRKDZql3m/MX6cI838zpHfrbenXE1EeZUGCc jF5b+OeEhw5QOY0n6w2f =eoSD -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
