Open Stack

I second the conf.d model.

Regards,
Mandeep


On Sun, May 4, 2014 at 10:13 AM, John Dickinson <me at 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. <armamig at 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 <mmcclain at yahoo-inc.com> wrote:
> >>
> >> 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
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140504/561140cc/attachment.html>