On 02/05/14 22:09, Mark McClain wrote: > > On May 2, 2014, at 7:39 AM, Sean Dague <[email protected]> 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?
What do operators want? _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
