-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nah, pointing --config-dir, either as one or as one of many arguments, is just plain wrong. We want to have a way to set different configuration values for different services, so merging all configuration files into single pile of Neutron Configuration is not something we should consider.
On 04/17/2015 11:17 PM, Kevin Benton wrote: > 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 <mailto:ihrac...@redhat.com>> wrote: > > 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 > <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> > <mailto: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/opensta c > >> k- > > > neutron.spec#L602 >> <https://github.com/openstack-packages/neutron/blob/f20-master/openst a > >> ck- > > > neutron.spec#L602> >> [2]: >> https://github.com/openstack-packages/neutron/blob/f20-master/neutron - - > >> l3 > <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-decomposi t > >>> i > >>> > on > > >> [2]: >>> http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutro n > >>> # > >>> > n393 >> <http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutro n > >> # > > > n393> > > >> [3]: >>> https://github.com/openstack-packages/neutron/blob/f20-master/neutro n > >>> - - > >>> > l3-agent.service#L8 >> <https://github.com/openstack-packages/neutron/blob/f20-master/neutro n > >> - - > > > l3-agent.service#L8> > > >> [4]: https://review.gerrithub.io/#/c/218562/ >>> [5]: >>> https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-file s > >>> / > >>> > >> [6]: >>> https://github.com/openstack-packages/neutron/blob/f20-master/neutro n > >>> - - > >>> > dist.conf > > >> [7]: >>> https://github.com/openstack-packages/neutron/blob/f20-master/openst a > >>> c > >>> > k-neutron.spec#L700 >> <https://github.com/openstack-packages/neutron/blob/f20-master/openst a > >> 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://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://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://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 iQEcBAEBAgAGBQJVNLQDAAoJEC5aWaUY1u579m4H/jDLZ0b97TkiRNuq1wK/sd7N TuP4V4Wx76Ra/tIxYE7k1h6f8NtyBYd+wX/lwN2kbKbW3KnNi1BjgYxMyi1NlN60 VkBpxgBRZfj8o+taRT6rPufGso8CMI0DcrBJV+FLRUkTSCjzGPinLcyvNCgHS4Ow kC5wvD5n3YREaoI8OSM+0cEY36RZUIm7S/m1QFfIdutwpYJVnFZzMLvK/BxnEZds GIgMd1eYpH/f+7LGPQQDLhmsxsHeFIfQsEfv/CGd084UHar8VWvChovJTrrlPZ9z srH5TJrnFGOgB+Wwp7jzhnoYkV7JnV+oieJ+E2vBmIgj5or2B15yFyRuvYIp2gw= =w2IH -----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
