Open Stack

On May 2, 2014, at 7:39 AM, Sean Dague <sean at 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 on config files. Neutron seems to have *a ton* of
> config files and is extremely sensitive to their locations/naming, which
> also seems like it ends up in flux.

We have grown in the number of configuration files and I do think some of the design decisions made several years ago should probably be revisited.  One of the drivers of multiple configuration files is the way that Neutron is currently packaged [1][2].  We’re packaged significantly different than the other projects so the thinking in the early years was that each plugin/service since it was packaged separately needed its own config file.  This causes problems because often it involves changing the init script invocation if the plugin is changed vs only changing the contents of the init script.  I’d like to see Neutron changed to be a single package similar to the way Cinder is packaged with the default config being ML2.

> 
> Is there an overview somewhere to explain this design point?

Sadly no.  It’s a historical convention that needs to be reconsidered.

> 
> All the other services have a single config config file designation on
> startup, but neutron services seem to need a bunch of config files
> correct on the cli to function (see this process list from recent
> grenade run - http://paste.openstack.org/show/78430/ note you will have
> to horiz scroll for some of the neutron services).
> 
> Mostly it would be good to understand this design point, and if it could
> be evolved back to the OpenStack norm of a single config file for the
> services.
> 

+1 to evolving into a more limited set of files.  The trick is how we consolidate the agent, server, plugin and/or driver options or maybe we don’t consolidate and use config-dir more.  In some cases, the files share a set of common options and in other cases there are divergent options [3][4].   Outside of testing the agents are not installed on the same system as the server, so we need to ensure that the agent configuration files should stand alone.  

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 (all plugin/service config files )
	service.d (all service config files)


Hypervisor Agents
/etc/neutron
	neutron.conf
	agent.d (Individual agent config files)


The invocations would then be static:

neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d

Service Agents:
neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d

Hypervisors (assuming the consolidates L2 is finished this cycle):
neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d

Thoughts?

mark

[1] http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/
[2] http://packages.ubuntu.com/search?keywords=neutron&searchon=names&suite=trusty&section=all
[3] https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2
[4]https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3