-----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: > [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
