[openstack-dev] [packaging][neutron] --config-dir vs. --config-file

Ihar Hrachyshka ihrachys at redhat.com
Mon Apr 20 08:08:35 UTC 2015


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

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-----



More information about the OpenStack-dev mailing list