<div dir="ltr">Great! I was just worried that it was going to become one --config-dir option that pointed to /etc/neutron or something.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 7:13 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span><span class="">On 04/13/2015 09:45 PM, Kevin Benton wrote:<br>
> What is the order of priority between the same option defined in<br>
> two files with --config-dir?<br>
<br>
</span>Should be alphabetically sorted, but it's not yet defined in<br>
documentation. I've sent a patch for this:<br>
<a href="https://review.openstack.org/174883" target="_blank">https://review.openstack.org/174883</a><br>
<span class=""><br>
><br>
> With '--config-file' args it seemed that it was that the latter<br>
> ones took priority over the earlier ones. So an admin previously<br>
> had the ability to abuse that by putting all of the desired global<br>
> settings in one of the earlier loaded configs and then add some<br>
> node-specific overrides to the ones loaded later.<br>
<br>
</span>It's not actually an abuse, but behaviour that is guaranteed by public<br>
library documentation, and it's fine to rely on it.<br>
<span class=""><br>
><br>
> Will there still be the ability to do that with RDO?<br>
<br>
</span>Nothing changes for users who do not want to use conf.d directory and<br>
instead store their configuration in upstream config files (like<br>
neutron.conf or l3_agent.ini). RDO/neutron only *extends*<br>
possibilities to configure services with the new conf.d feature.<br>
<br>
The order of configuration storages as they are currently loaded in<br>
RDO/neutron services is the same for all of them, and can be checked<br>
in any systemd service file:<br>
<br>
<a href="https://github.com/openstack-packages/neutron/blob/f20-master/neutron-me
tadata-agent.service#L8" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/neutron-me<br>
tadata-agent.service#L8</a><br>
<br>
The way it's defined there, conf.d beats all other configuration<br>
files. But if you don't buy the new approach, you just don't have any<br>
files inside the directory to beat your conventional configuration.<br>
<span class=""><br>
><br>
> On Mon, Apr 13, 2015 at 8:25 AM, Ihar Hrachyshka<br>
</span><span class="">> <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a> <mailto:<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> RDO/master (aka Delorean) moved neutron l3 agent to this<br>
> configuration scheme, configuring l3 (and vpn) agent with<br>
> --config-dir [1][2][3].<br>
><br>
> We also provided a way to configure neutron services without ever<br>
> touching a single configuration file from the package [4] where<br>
> each service has a config-dir located under<br>
> /etc/neutron/conf.d/<service-name> that can be populated by *.conf<br>
> files that will be automatically read by services during startup.<br>
><br>
> All other distributions are welcome to follow the path. Please<br>
> don't introduce your own alternative to /etc/neutron/conf.d/...<br>
> directory to avoid unneeded platform dependent differences in<br>
> deployment tools.<br>
><br>
> As for devstack, it's not really feasible to introduce such a<br>
> change there (at least from my perspective), so it's downstream<br>
> only.<br>
><br>
> [1]:<br>
> <a href="https://github.com/openstack-packages/neutron/blob/f20-master/openstac" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/openstac</a><br>
k-<br>
><br>
><br>
neutron.spec#L602<br>
</span><span class="">> <<a href="https://github.com/openstack-packages/neutron/blob/f20-master/opensta" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/opensta</a><br>
ck-<br>
><br>
><br>
neutron.spec#L602><br>
> [2]:<br>
> <a href="https://github.com/openstack-packages/neutron/blob/f20-master/neutron-
l3" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/neutron-<br>
l3</a><br>
><br>
><br>
- -agent.service#L8<br>
> [3]:<br>
> <a href="https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/o" target="_blank">https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/o</a><br>
pe<br>
><br>
><br>
nstack-neutron-vpnaas.spec#L97<br>
</span>> <<a href="https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/" target="_blank">https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/</a><br>
<div><div class="h5">ope<br>
><br>
><br>
nstack-neutron-vpnaas.spec#L97><br>
> [4]: <a href="https://review.gerrithub.io/#/c/229162/" target="_blank">https://review.gerrithub.io/#/c/229162/</a><br>
><br>
> Thanks, /Ihar<br>
><br>
> On 03/13/2015 03:11 PM, Ihar Hrachyshka wrote:<br>
>> Hi all,<br>
><br>
>> (I'm starting a new [packaging] tag in this mailing list to<br>
>> reach out people who are packaging our software in distributions<br>
>> and whatnot.)<br>
><br>
>> Neutron vendor split [1] introduced situations where the set of<br>
>> configuration files for L3/VPN agent is not stable and depends<br>
>> on which packages are installed in the system. Specifically,<br>
>> fwaas_driver.ini file is now shipped in neutron_fwaas tarball<br>
>> (openstack-neutron-fwaas package in RDO), and so<br>
>> --config-file=/etc/neutron/fwaas_driver.ini argument should be<br>
>> passed to L3/VPN agent *only* when the new package with the file<br>
>> is installed.<br>
><br>
>> In devstack, we solve the problem by dynamically generating CLI<br>
>> arguments list based on which services are configured in<br>
>> local.conf [2]. It's not a viable approach in proper<br>
>> distribution packages though, where we usually hardcode arguments<br>
>> [3] in our service manifests (systemd unit files, in case of<br>
>> RDO).<br>
><br>
>> The immediate solution to solve the issue would be to use<br>
>> --config-dir argument that is also provided to us by oslo.config<br>
>> instead of --config-file, and put auxiliary files there [4]<br>
>> (those may be just symbolic links to actual files).<br>
><br>
>> I initially thought to put the directory under /etc/neutron/,<br>
>> but then realized we may be interested in keeping it out of user<br>
>> sight while it only references stock (upstream) configuration<br>
>> files.<br>
><br>
>> But then a question arises: whether it's useful just for this<br>
>> particular case? Maybe there is value in using --config-dir<br>
>> outside of it? And in that case, maybe the approach should be<br>
>> replicated to other services?<br>
><br>
>> AFAIU --config-dir could actually be useful to configure<br>
>> services. Now instead of messing with configuration files that<br>
>> are shipped with packages (and handling .rpmnew files [5] that<br>
>> are generated on upgrade when local changes to those files are<br>
>> detected), users (or deployment/installation tools) could instead<br>
>> drop a *.conf file in that configuration directory, being sure<br>
>> their stock configuration file is always current, and no .rpmnew<br>
>> files are there to manually solve conflicts).<br>
><br>
>> We can also use two --config-dir arguments, one for<br>
>> stock/upstream configuration files, located out of /etc/neutron/,<br>
>> and another one available for population with user configuration<br>
>> files, under /etc/neutron/. This is similar to how we put<br>
>> settings considered to be 'sane distro defaults' in<br>
>> neutron-dist.conf file that is not available for modification<br>
>> [6][7].<br>
><br>
>> Of course users would still be able to set up their deployment<br>
>> the old way. In that case, nothing will change for them. So the<br>
>> approach is backwards compatible.<br>
><br>
>> I wonder whether the idea seems reasonable and actually useful<br>
>> for people. If so, we may want to come up with some packaging<br>
>> standards (on where to put those config-dir(s), how to name<br>
>> them, how to maintain symbolic links inside them) to avoid more<br>
>> work for deployment tools.<br>
><br>
>> [1]:<br>
</div></div><span class="">>> <a href="https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposit" target="_blank">https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposit</a><br>
i<br>
><br>
>><br>
on<br>
><br>
><br>
> [2]:<br>
>> <a href="http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron" target="_blank">http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron</a><br>
#<br>
><br>
>><br>
n393<br>
> <<a href="http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron" target="_blank">http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron</a><br>
#<br>
><br>
><br>
n393><br>
><br>
><br>
> [3]:<br>
>> <a href="https://github.com/openstack-packages/neutron/blob/f20-master/neutron" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/neutron</a><br>
</span>- -<br>
><br>
>><br>
l3-agent.service#L8<br>
> <<a href="https://github.com/openstack-packages/neutron/blob/f20-master/neutron" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/neutron</a><br>
- -<br>
<span class="">><br>
><br>
l3-agent.service#L8><br>
><br>
><br>
> [4]: <a href="https://review.gerrithub.io/#/c/218562/" target="_blank">https://review.gerrithub.io/#/c/218562/</a><br>
>> [5]:<br>
>> <a href="https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-files" target="_blank">https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-files</a><br>
/<br>
><br>
>><br>
><br>
> [6]:<br>
>> <a href="https://github.com/openstack-packages/neutron/blob/f20-master/neutron" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/neutron</a><br>
</span>- -<br>
<span class="">><br>
>><br>
dist.conf<br>
><br>
><br>
> [7]:<br>
>> <a href="https://github.com/openstack-packages/neutron/blob/f20-master/opensta" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/opensta</a><br>
c<br>
><br>
>><br>
k-neutron.spec#L700<br>
> <<a href="https://github.com/openstack-packages/neutron/blob/f20-master/opensta" target="_blank">https://github.com/openstack-packages/neutron/blob/f20-master/opensta</a><br>
c<br>
><br>
><br>
k-neutron.spec#L700><br>
><br>
>> Regards, /Ihar<br>
><br>
>> /Ihar<br>
><br>
>> _____________________________________________________________________<br>
_<br>
><br>
>><br>
</span><span class="">____<br>
><br>
><br>
> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
>><br>
><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<span class="">><br>
><br>
> ______________________________________________________________________<br>
____<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
<span class="">><br>
><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> -- Kevin Benton<br>
><br>
><br>
</span><span class="">> ______________________________________________________________________<br>
____<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
</span>iQEcBAEBAgAGBQJVMRUOAAoJEC5aWaUY1u57lysH/Arx93DCQCjTNJlE9nUvug0g<br>
4LwY3QPpB1jhuOw6V2Zwl+PkAV3+UWEsvk+C5CmVEV2nJjd++gAeoEhc3Zsgu4Gf<br>
exvQoScrQfdw0tG32c/WEYmiSYvCWxRARkJV+9t60VQtB2W04S1IeCk8hh2+Wxk5<br>
j1VH6aq4br8GvjvJAC8OM5dHdFmDZwXG4zUzcdk+PAKs5I6CYL9LpWfRI3V4/b+g<br>
vzIS8v5/9qHP5rbKkFTvHKwohMf2UQF+psGeyYdpjJFnKMUdYa3RcCMe+KbdTKg+<br>
ARIP6h1xEOgDcHbzvl36JJ0gjE8dg6fxOZIOV3ZhZg3ch26VKAHUXOnG5aDYX94=<br>
=NI+S<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>