[openstack-dev] [packaging][neutron] --config-dir vs. --config-file
openstack at nemebean.com
Fri Mar 13 18:53:36 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 03/13/2015 09:11 AM, 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
> 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
> 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 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  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 .
> 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.
This is essentially what tripleo does as well, for similar reasons I
believe. For example, nova-api is configured like this:
Maybe a little hard to parse if you're not familiar with
os-svc-daemon, but essentially it's starting nova-api with
"--config-dir /etc/nova --config-dir /etc/nova/api" so we can
configure nova-api without stepping on any other service, and still
have common configs in /etc/nova.
AFAIK it has worked well for us, and it does seem like a more flexible
way to handle configs so +1 to doing it elsewhere too.
> Regards, /Ihar
OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the OpenStack-dev