I second the conf.d model. Regards, Mandeep
On Sun, May 4, 2014 at 10:13 AM, John Dickinson <m...@not.mn> wrote: > To add some color, Swift supports both single conf files and conf.d > directory-based configs. See > http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration > . > > The "single config file" pattern is quite useful for simpler > configurations, but the directory-based ones becomes especially useful when > looking at cluster configuration management tools--stuff that > auto-generates and composes config settings (ie non hand-curated configs). > For example, the conf.d configs can support each middleware config or > background daemon process in a separate file. Or server settings in one > file and common logging settings in another. > > (Also, to answer before it's asked [but I don't want to derail the current > thread], I'd be happy to look at oslo config parsing if it supports the > same functionality.) > > --John > > > > > On May 4, 2014, at 9:49 AM, Armando M. <arma...@gmail.com> wrote: > > > If the consensus is to unify all the config options into a single > > configuration file, I'd suggest following what the Nova folks did with > > [1], which I think is what Salvatore was also hinted. This will also > > help mitigate needless source code conflicts that would inevitably > > arise when merging competing changes to the same file. > > > > I personally do not like having a single file with gazillion options > > (the same way I hate source files with gazillion LOC's but I digress > > ;), but I don't like a proliferation of config files either. So I > > think what Mark suggested below makes sense. > > > > Cheers, > > Armando > > > > [1] - > https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt > > > > On 2 May 2014 07:09, Mark McClain <mmccl...@yahoo-inc.com> wrote: > >> > >> On May 2, 2014, at 7:39 AM, Sean Dague <s...@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§ion=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 > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev