Open Stack

-----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
> <ihrachys at redhat.com <mailto:ihrachys at 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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe 
> <http://OpenStack-dev-request@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-request at 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-----