Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
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
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-decomposition
[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/openstack-neutron.spec#L700

Regards,
/Ihar

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAu/8AAoJEC5aWaUY1u57yx4H/0AE+8LH6wByyBQAGvcSU0i7
0BNThPS2sy0sPEHIZCH7OH3prAAyG0IFb2NNyHvMjTbVHPR+wjavsxPcAth09vrh
rQgnSTA9IkdX2w1+M/vKu0QKUPNQrs5KVIchUatsoReeM9Mmrq6YqG56dEx33Emi
FvpTb7B6V4EOvrCRp6TT4gOHOrHO5kwa62sXSFP8+IpzOcOKeO9XTFTC7PeKFtMi
AHwjvpHjnOl8bNpTbGz5nVZkAT/XTv0TiiPIQF7NFPIkzlan4E/K04N8DIis5fdA
P+8eDaEGDxsW4LYZ9AfITml3G0uVqcpiRIwwIL4f84ubQKjSARW8Roi1FwPSsbI=
=gkZr
-----END PGP SIGNATURE-----