Great! I was just worried that it was going to become one --config-dir option that pointed to /etc/neutron or something.
On Fri, Apr 17, 2015 at 7:13 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 04/13/2015 09:45 PM, Kevin Benton wrote: > > What is the order of priority between the same option defined in > > two files with --config-dir? > > Should be alphabetically sorted, but it's not yet defined in > documentation. I've sent a patch for this: > https://review.openstack.org/174883 > > > > > 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. > > It's not actually an abuse, but behaviour that is guaranteed by public > library documentation, and it's fine to rely on it. > > > > > Will there still be the ability to do that with RDO? > > Nothing changes for users who do not want to use conf.d directory and > instead store their configuration in upstream config files (like > neutron.conf or l3_agent.ini). RDO/neutron only *extends* > possibilities to configure services with the new conf.d feature. > > The order of configuration storages as they are currently loaded in > RDO/neutron services is the same for all of them, and can be checked > in any systemd service file: > > https://github.com/openstack-packages/neutron/blob/f20-master/neutron-me > tadata-agent.service#L8 > > The way it's defined there, conf.d beats all other configuration > files. But if you don't buy the new approach, you just don't have any > files inside the directory to beat your conventional configuration. > > > > > 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/openstac > k- > > > > > neutron.spec#L602 > > <https://github.com/openstack-packages/neutron/blob/f20-master/opensta > ck- > > > > > 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 > > <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-decomposit > i > > > >> > 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 > # > > > > > n393> > > > > > > [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 > - - > > > > > 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 > > <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: > >> 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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBAgAGBQJVMRUOAAoJEC5aWaUY1u57lysH/Arx93DCQCjTNJlE9nUvug0g > 4LwY3QPpB1jhuOw6V2Zwl+PkAV3+UWEsvk+C5CmVEV2nJjd++gAeoEhc3Zsgu4Gf > exvQoScrQfdw0tG32c/WEYmiSYvCWxRARkJV+9t60VQtB2W04S1IeCk8hh2+Wxk5 > j1VH6aq4br8GvjvJAC8OM5dHdFmDZwXG4zUzcdk+PAKs5I6CYL9LpWfRI3V4/b+g > vzIS8v5/9qHP5rbKkFTvHKwohMf2UQF+psGeyYdpjJFnKMUdYa3RcCMe+KbdTKg+ > ARIP6h1xEOgDcHbzvl36JJ0gjE8dg6fxOZIOV3ZhZg3ch26VKAHUXOnG5aDYX94= > =NI+S > -----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 > -- 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
