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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
