[openstack-dev] [rpm-packaging][chef][puppet][salt][openstack-ansible][HA] Schema proposal for config file handling for services

Thomas Bechtold tbechtold at suse.com
Mon Oct 10 11:03:30 UTC 2016


Hi,

in the rpm-packaging project we started to package the services and are
currently discussing a possible schema for configuration files and
snippets used by the systemd .service files (but this would also affect
OCF resource agents).
This affects packagers, endusers and config management systems (Chef,
Puppet, Ansible, Salt, ...) so I want to discuss the proposal here on
the list.

Most services (at least for SUSE and RDO) are using a single config
(e.g. /etc/nova/nova.conf) when starting the service. Some services
(e.g. neutron services like neutron-l3-agent) use multiple config files.

There are multiple problems with that approach:
- when using a config-mgmt-system, users may want to override a config
option (for a feature that is not yet supported) but the
config-mgmt-system will override the config later again.
- when users adjust /etc/$service/$service.conf and a release update is
done (e.g. mitaka->newton) /etc/$service/$service.conf wil not be
overridden. That's good because the user changed something but otoh the
file (with all it's config options and comments) is no longer correct.
- when config-mgmt-systems use templates for the $service.conf file,
updating theses templates is a lot of work.
- setting configuration options per service (let's say cinder-volume
needs other config options than cinder-api) is not possible.

So here's the proposal to fix theses problems. The proposal is based on
what RDO is already doing with neutron and extends it a bit. Let's do it
for Nova as an example:

- /usr/share/nova/nova-dist.conf
This is the configuration file a distribution (openSUSE, RDO, ...) can
modify. It must not be modified by endusers and will be overridden with
package updates

- /etc/nova/nova.conf
This is an empty file . Users/config-mgmt-systems can modify it and it
will not be overridden (if changed) with a package update.

- /etc/nova/conf.d/common/
In this directory, config snippets can be added. By convention,
config-mgmt-systems would install files starting with 100-XXX.conf,
endusers would install files starting with 500-XXX.conf . Also this
directory is used by all services (nova-api, nova-compute, ...).

- /etc/nova/conf.d/$service/ (e.g. /etc/nova/conf.d/nova-compute/)
Also a dir for config snippets (with same rules as for
/etc/nova/conf.d/common/ ) but this dir is only used by $service (in
this case nova-compute)

- /usr/share/doc/packages/openstack-nova/nova.conf.sample
The unmodified sample config from upstream

- /etc/nova/README
Explaining the configuration structure and where to find the whole
sample config.


So starting nova-api would be:
nova-api --config-file /usr/share/nova/nova-dist.conf
         --config-file /etc/nova/nova.conf
         --config-dir /etc/nova/conf.d/common/
         --config-dir /etc/nova/conf.d/nova-api/


The order of command line switches (--config-file/--config-dir) is
important here. Also --config-dir is ordering the files. So adding a
config snippet to /etc/nova/conf.d/nova-api/ with
e.g. [DEFAULT]bind_port would override the option from the previous
configs (last found option wins).


Feedback very welcome!

Cheers,

Tom



More information about the OpenStack-dev mailing list