The loading seems to me in a sorted order, so we can do 1.conf 2.conf etc. https://github.com/openstack/oslo.config/blob/1.9.3/oslo_config/cfg.py#L1265-L1268
On 04/13/2015 02:45 PM, Kevin Benton wrote: > What is the order of priority between the same option defined in two > files with --config-dir? > > With '--config-file' args it seemed that it was that the latter ones > took priority over the earlier ones. So an admin previously had the > ability to abuse that by putting all of the desired global settings in > one of the earlier loaded configs and then add some node-specific > overrides to the ones loaded later. > > Will there still be the ability to do that with RDO? > > On Mon, Apr 13, 2015 at 8:25 AM, Ihar Hrachyshka <ihrac...@redhat.com > <mailto:ihrac...@redhat.com>> 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/openstack- > neutron.spec#L602 > <https://github.com/openstack-packages/neutron/blob/f20-master/openstack-%0Aneutron.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 > <https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/ope%0Anstack-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 > <http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#%0An393> > > > [3]: >> https://github.com/openstack-packages/neutron/blob/f20-master/neutron- > l3-agent.service#L8 > <https://github.com/openstack-packages/neutron/blob/f20-master/neutron-%0Al3-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 > <https://github.com/openstack-packages/neutron/blob/f20-master/openstac%0Ak-neutron.spec#L700> > >> Regards, /Ihar > >> /Ihar > >> ______________________________________________________________________ > ____ > > > OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Kevin Benton > > > __________________________________________________________________________ > 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 > -- Matthew Thode -- -- Matthew Thode (prometheanfire)
signature.asc
Description: OpenPGP digital 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
