Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-05 Thread Thomas Goirand
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-05 Thread Jay Pipes
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-05 Thread Doug Hellmann
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Sean Dague
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Mark McClain
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.

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Armando M.
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread John Dickinson
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Mandeep Dhami
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread gustavo panizzo gfa
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Kevin Benton
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-03 Thread Tom Fifield
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-03 Thread Kashyap Chamarthy
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-03 Thread gustavo panizzo gfa
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

[openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-02 Thread Sean Dague
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-02 Thread Kyle Mestery
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-02 Thread Mark McClain
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

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-02 Thread Mark T. Voelker
-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