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

Ihar Hrachyshka ihrachys at redhat.com
Thu Apr 23 12:41:46 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I just realized that while RDO now has a way to configure each service
separately with user defined configuration file, there is still one
limitation - a replacement for neutron.conf that contains lots of
options that are common to all services. I think we should also add a
new config-directory that would be loaded by *all* services.

I wonder what people think about its name. I think
/etc/neutron/conf.d/common is a good fit. Comments?

Ihar

On 04/13/2015 05:25 PM, Ihar Hrachyshka 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
> [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
> [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
> 
> 
> [3]:
>> 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
> 
>> Regards, /Ihar
> 
>> /Ihar
> 
>> _____________________________________________________________________
_
>
>> 
____
> 
> 
> 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
>
>> 
> 
> ______________________________________________________________________
____
>
> 
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

iQEcBAEBCAAGBQJVOOiKAAoJEC5aWaUY1u57dL0IAIowBiAZ7u9rY8HdpBelrWtN
XPKJtW7bRuMU38S2OCVYAQ7JETGD4Kljm4lIGb1TtgScojpvc+Rd3fDv473/2SL1
vFfwzUXbxcj5gDywgNl+99qdp5ySQYq/k+BYqz1rbyg4VKJfUJogrIj+iI0yP+nX
eb5E4Kwk6w21P8cUB+oUv0yyo+pIROC1aDacn6n/Ri0NH9BIgJs1CYAXGK8ECNHX
Dd/5bdd4zg3ECEP0DeX/DTGVt4BAxPf37E/EshJP4dPj+yA85cJ4/ZLJpZ6AJlOE
ep5yRGA6ctOp0Qev+oLRslklEPZU+6nVKYkXivWSIqm+WEo4ExRCOzHSZIfSEaM=
=hDCo
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list