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

Ihar Hrachyshka ihrachys at redhat.com
Fri Mar 13 14:11:08 UTC 2015

Hash: SHA1

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

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

[4]: https://review.gerrithub.io/#/c/218562/


Version: GnuPG v1


More information about the OpenStack-dev mailing list