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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev