-----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----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev