Open Stack

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.

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.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140108/70c7be50/attachment.pgp>