[openstack-dev] [packaging][neutron] --config-dir vs. --config-file

Kevin Benton blak111 at gmail.com
Mon Apr 13 19:45:24 UTC 2015


What is the order of priority between the same option defined in two files
with --config-dir?

With '--config-file' args it seemed that it was that the latter ones took
priority over the earlier ones. So an admin previously had the ability to
abuse that by putting all of the desired global settings in one of the
earlier loaded configs and then add some node-specific overrides to the
ones loaded later.

Will there still be the ability to do that with RDO?

On Mon, Apr 13, 2015 at 8:25 AM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> RDO/master (aka Delorean) moved neutron l3 agent to this configuration
> scheme, configuring l3 (and vpn) agent with --config-dir [1][2][3].
>
> We also provided a way to configure neutron services without ever
> touching a single configuration file from the package [4] where each
> service has a config-dir located under
> /etc/neutron/conf.d/<service-name> that can be populated by *.conf
> files that will be automatically read by services during startup.
>
> All other distributions are welcome to follow the path. Please don't
> introduce your own alternative to /etc/neutron/conf.d/... directory to
> avoid unneeded platform dependent differences in deployment tools.
>
> As for devstack, it's not really feasible to introduce such a change
> there (at least from my perspective), so it's downstream only.
>
> [1]:
> https://github.com/openstack-packages/neutron/blob/f20-master/openstack-
> neutron.spec#L602
> [2]:
> https://github.com/openstack-packages/neutron/blob/f20-master/neutron-l3
> - -agent.service#L8
> [3]:
> https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/ope
> nstack-neutron-vpnaas.spec#L97
> [4]: https://review.gerrithub.io/#/c/229162/
>
> Thanks,
> /Ihar
>
> On 03/13/2015 03:11 PM, Ihar Hrachyshka wrote:
> > Hi all,
> >
> > (I'm starting a new [packaging] tag in this mailing list to reach
> > out people who are packaging our software in distributions and
> > whatnot.)
> >
> > Neutron vendor split [1] introduced situations where the set of
> > configuration files for L3/VPN agent is not stable and depends on
> > which packages are installed in the system. Specifically,
> > fwaas_driver.ini file is now shipped in neutron_fwaas tarball
> > (openstack-neutron-fwaas package in RDO), and so
> > --config-file=/etc/neutron/fwaas_driver.ini argument should be
> > passed to L3/VPN agent *only* when the new package with the file is
> > installed.
> >
> > In devstack, we solve the problem by dynamically generating CLI
> > arguments list based on which services are configured in
> > local.conf [2]. It's not a viable approach in proper distribution
> > packages though, where we usually hardcode arguments [3] in our
> > service manifests (systemd unit files, in case of RDO).
> >
> > The immediate solution to solve the issue would be to use
> > --config-dir argument that is also provided to us by oslo.config
> > instead of --config-file, and put auxiliary files there [4] (those
> > may be just symbolic links to actual files).
> >
> > I initially thought to put the directory under /etc/neutron/, but
> > then realized we may be interested in keeping it out of user sight
> > while it only references stock (upstream) configuration files.
> >
> > But then a question arises: whether it's useful just for this
> > particular case? Maybe there is value in using --config-dir outside
> > of it? And in that case, maybe the approach should be replicated to
> > other services?
> >
> > AFAIU --config-dir could actually be useful to configure services.
> > Now instead of messing with configuration files that are shipped
> > with packages (and handling .rpmnew files [5] that are generated on
> > upgrade when local changes to those files are detected), users (or
> > deployment/installation tools) could instead drop a *.conf file in
> > that configuration directory, being sure their stock configuration
> > file is always current, and no .rpmnew files are there to manually
> > solve conflicts).
> >
> > We can also use two --config-dir arguments, one for stock/upstream
> > configuration files, located out of /etc/neutron/, and another one
> > available for population with user configuration files, under
> > /etc/neutron/. This is similar to how we put settings considered to
> > be 'sane distro defaults' in neutron-dist.conf file that is not
> > available for modification [6][7].
> >
> > Of course users would still be able to set up their deployment the
> > old way. In that case, nothing will change for them. So the
> > approach is backwards compatible.
> >
> > I wonder whether the idea seems reasonable and actually useful for
> > people. If so, we may want to come up with some packaging
> > standards (on where to put those config-dir(s), how to name them,
> > how to maintain symbolic links inside them) to avoid more work for
> > deployment tools.
> >
> > [1]:
> > https://blueprints.launchpad.net/neutron/+spec/core-vendor-decompositi
> on
> >
> >
> [2]:
> > http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#
> n393
> >
> >
> [3]:
> > https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
> l3-agent.service#L8
> >
> >
> [4]: https://review.gerrithub.io/#/c/218562/
> > [5]:
> > https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-files/
> >
> >
> [6]:
> > https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
> dist.conf
> >
> >
> [7]:
> > https://github.com/openstack-packages/neutron/blob/f20-master/openstac
> k-neutron.spec#L700
> >
> >  Regards, /Ihar
> >
> > /Ihar
> >
> > ______________________________________________________________________
> ____
> >
> >
> OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBAgAGBQJVK9/9AAoJEC5aWaUY1u57phQIAJIy4Q/cnINfS5UPDSv65I59
> +lQKu9HXX/hEI0A1wVtpjXEsXiyUWlyZTBTYPmRXEH1nhhznCO5dRPtJ0I9N9NoZ
> CA04bdxnJll8PYp16+i9YCdCQoE9DSoT1Qr4JimMFA2ZVS4E0P3WP486s1tMmoaL
> mLKBPrm8Y0YGsJYOENG8aeMuNI16pjdWRYx9icxUdpD3lOZc/kzxbaBf595jIUUn
> VHGJCUTUBsI/0S0gCDe7B046JCFnDfxfza/WlCzHXOjZ+fPJCgl/+RzsjPJ7k4Q+
> Eu7JQEHMQ3tY0bR5DHuBseVmuRlfvztx7i6EdrWTvdm4LH5Q3QqdA0vHr6tZ/qk=
> =y8b1
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150413/14f02201/attachment.html>


More information about the OpenStack-dev mailing list