-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I just realized that while RDO now has a way to configure each service separately with user defined configuration file, there is still one limitation - a replacement for neutron.conf that contains lots of options that are common to all services. I think we should also add a new config-directory that would be loaded by *all* services.
I wonder what people think about its name. I think /etc/neutron/conf.d/common is a good fit. Comments? Ihar On 04/13/2015 05:25 PM, Ihar Hrachyshka wrote: > 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/openstac k- > > 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/o pe > > 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-decomposit i > >> 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/opensta c > >> 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 > >> > > ______________________________________________________________________ ____ > > 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 iQEcBAEBCAAGBQJVOOiKAAoJEC5aWaUY1u57dL0IAIowBiAZ7u9rY8HdpBelrWtN XPKJtW7bRuMU38S2OCVYAQ7JETGD4Kljm4lIGb1TtgScojpvc+Rd3fDv473/2SL1 vFfwzUXbxcj5gDywgNl+99qdp5ySQYq/k+BYqz1rbyg4VKJfUJogrIj+iI0yP+nX eb5E4Kwk6w21P8cUB+oUv0yyo+pIROC1aDacn6n/Ri0NH9BIgJs1CYAXGK8ECNHX Dd/5bdd4zg3ECEP0DeX/DTGVt4BAxPf37E/EshJP4dPj+yA85cJ4/ZLJpZ6AJlOE ep5yRGA6ctOp0Qev+oLRslklEPZU+6nVKYkXivWSIqm+WEo4ExRCOzHSZIfSEaM= =hDCo -----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
