Open Stack

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?

Best,
-jay