Open Stack

----- Original Message -----
> From: "Jay Pipes" <jaypipes at gmail.com>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, January 8, 2014 2:29:22 PM
> Subject: Re: [openstack-dev] [Neutron] Multiple config files for neutron server
> 
> On Wed, 2014-01-08 at 07:21 -0500, Sean Dague wrote:
> > On 01/06/2014 02:58 PM, Jay Pipes wrote:
> > > On Mon, 2014-01-06 at 23:45 +0400, Eugene Nikanorov wrote:
> > >> Hi folks,
> > >>
> > >>
> > >> Recently we had a discussion with Sean Dague on the matter.
> > >> Currently Neutron server has a number of configuration files used for
> > >> different purposes:
> > >>  - neutron.conf - main configuration parameters, plugins, db and mq
> > >> connections
> > >>  - plugin.ini - plugin-specific networking settings
> > >>  - conf files for ml2 mechanisms drivers (AFAIK to be able to use
> > >> several mechanism drivers we need to pass all of these conf files to
> > >> neutron server)
> > >>  - services.conf - recently introduced conf-file to gather
> > >> vendor-specific parameters for advanced services drivers.
> > >> Particularly, services.conf was introduced to avoid polluting
> > >> 'generic' neutron.conf with vendor parameters and sections.
> > >>
> > >>
> > >> The discussion with Sean was about whether to add services.conf to
> > >> neutron-server launching command in devstack
> > >> (https://review.openstack.org/#/c/64377/ ). services.conf would be 3rd
> > >> config file that is passed to neutron-server along with neutron.conf
> > >> and plugin.ini.
> > >>
> > >>
> > >> Sean has an argument that providing many conf files in a command line
> > >> is not a good practice, suggesting setting up configuration directory
> > >> instead. There is no such capability in neutron right now so I'd like
> > >> to hear opinions on this before putting more efforts in resolving this
> > >> in with other approach than used in the patch on review.
> > > 
> > > I'd say just put the additional conf file on the command line for now.
> > > Adding in support to oslo.cfg for a config directory can come later.
> > > 
> > > Just my 2 cents,
> > 
> > So the net of that is that in a production environment, in order to
> > change some services, you'd be expected to change the init scripts to
> > list the right config files.
> 
> Good point.
> 
> > That seems *really* weird, and also really different from the rest of
> > OpenStack services. It also means you can't use the oslo config
> > generator to generate documented samples.
> > 
> > If neutron had been running a grenade job, it would have blocked this
> > attempted change, because it would require adding config files between
> > releases.
> > 
> > So this all smells pretty bad to me. Especially in the context of
> > migration paths from nova (which handles this very differently) => neutron.
> 
> So, I was under the impression that the Neutron changes to require a
> services.conf had *already* been merged into master, and therefore the
> problem domain here was not whether the services.conf addition was the
> right approach, but rather *how to deal with it in devstack*, and that's
> why I wrote to just add it to the command line in the devstack builder.
> 
> A better (upstream in Neutron) solution would have been to use something
> like an include.d/ directive in the nova.conf. But I thought that we
> were past the implementation point in Neutron?

Doesn't neutron already support what we need here:

./neutron-server --help | grep config-dir
usage: neutron-server [-h] [--config-dir DIR] [--config-file PATH] [--debug]
  --config-dir DIR      Path to a config directory to pull *.conf files from.

It would seem that with proper organization devstack could take advantage of this already no?

> 
> Best,
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>