[openstack-dev] [packaging][neutron] --config-dir vs. --config-file
doug at doughellmann.com
Fri Mar 13 15:33:51 UTC 2015
On Fri, Mar 13, 2015, at 10:11 AM, Ihar Hrachyshka wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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  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
> . It's not a viable approach in proper distribution packages
> though, where we usually hardcode arguments  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  (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
> 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  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).
The --config-dir option was added at the request of some of the folks
working on deployment automation (I don't remember if it was the puppet
folks, the chef folks, or both) because it's easier to add a file than
to modify one.
So yes, if each driver or add-on or whatever uses a separate file *and
configuration section* for its overrides, oslo.config can just read all
of the files and merge them together. Only the options actually being
used by running code will be validated, so there's no harm in deploying
"extra" configuration files.
> 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 .
> 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
> : https://review.gerrithub.io/#/c/218562/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> -----END PGP SIGNATURE-----
> OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev