<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I second the conf.d model.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
Regards,</div><div class="gmail_default" style="font-size:small">Mandeep</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 4, 2014 at 10:13 AM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn" target="_blank">me@not.mn</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">To add some color, Swift supports both single conf files and conf.d directory-based configs. See <a href="http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration" target="_blank">http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration</a>.<br>
<br>
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.<br>
<br>
(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.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--John<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On May 4, 2014, at 9:49 AM, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>> wrote:<br>
<br>
> If the consensus is to unify all the config options into a single<br>
> configuration file, I'd suggest following what the Nova folks did with<br>
> [1], which I think is what Salvatore was also hinted. This will also<br>
> help mitigate needless source code conflicts that would inevitably<br>
> arise when merging competing changes to the same file.<br>
><br>
> I personally do not like having a single file with gazillion options<br>
> (the same way I hate source files with gazillion LOC's but I digress<br>
> ;), but I don't like a proliferation of config files either. So I<br>
> think what Mark suggested below makes sense.<br>
><br>
> Cheers,<br>
> Armando<br>
><br>
> [1] - <a href="https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt" target="_blank">https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt</a><br>
><br>
> On 2 May 2014 07:09, Mark McClain <<a href="mailto:mmcclain@yahoo-inc.com">mmcclain@yahoo-inc.com</a>> wrote:<br>
>><br>
>> On May 2, 2014, at 7:39 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
>><br>
>>> Some non insignificant number of devstack changes related to neutron<br>
>>> seem to be neutron plugins having to do all kinds of manipulation of<br>
>>> extra config files. The grenade upgrade issue in neutron was because of<br>
>>> some placement change on config files. Neutron seems to have *a ton* of<br>
>>> config files and is extremely sensitive to their locations/naming, which<br>
>>> also seems like it ends up in flux.<br>
>><br>
>> 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.<br>
>><br>
>>><br>
>>> Is there an overview somewhere to explain this design point?<br>
>><br>
>> Sadly no. It’s a historical convention that needs to be reconsidered.<br>
>><br>
>>><br>
>>> All the other services have a single config config file designation on<br>
>>> startup, but neutron services seem to need a bunch of config files<br>
>>> correct on the cli to function (see this process list from recent<br>
>>> grenade run - <a href="http://paste.openstack.org/show/78430/" target="_blank">http://paste.openstack.org/show/78430/</a> note you will have<br>
>>> to horiz scroll for some of the neutron services).<br>
>>><br>
>>> Mostly it would be good to understand this design point, and if it could<br>
>>> be evolved back to the OpenStack norm of a single config file for the<br>
>>> services.<br>
>>><br>
>><br>
>> +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.<br>
>><br>
>> To throw something out, what if moved to using config-dir for optional configs since it would still support plugin scoped configuration files.<br>
>><br>
>> Neutron Servers/Network Nodes<br>
>> /etc/neutron.d<br>
>> neutron.conf (Common Options)<br>
>> server.d (all plugin/service config files )<br>
>> service.d (all service config files)<br>
>><br>
>><br>
>> Hypervisor Agents<br>
>> /etc/neutron<br>
>> neutron.conf<br>
>> agent.d (Individual agent config files)<br>
>><br>
>><br>
>> The invocations would then be static:<br>
>><br>
>> neutron-server —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/server.d<br>
>><br>
>> Service Agents:<br>
>> neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/service.d<br>
>><br>
>> Hypervisors (assuming the consolidates L2 is finished this cycle):<br>
>> neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir /etc/neutron/agent.d<br>
>><br>
>> Thoughts?<br>
>><br>
>> mark<br>
>><br>
>> [1] <a href="http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/" target="_blank">http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/epel-7/</a><br>
>> [2] <a href="http://packages.ubuntu.com/search?keywords=neutron&searchon=names&suite=trusty§ion=all" target="_blank">http://packages.ubuntu.com/search?keywords=neutron&searchon=names&suite=trusty§ion=all</a><br>
>> [3] <a href="https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2" target="_blank">https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/nuage/nuage_plugin.ini#n2</a><br>
>> [4]<a href="https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3" target="_blank">https://git.openstack.org/cgit/openstack/neutron/tree/etc/neutron/plugins/bigswitch/restproxy.ini#n3</a><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>