[openstack-dev] [deployment][tripleo][puppet] using puppet to push configuration into etcd

Emilien Macchi emilien at redhat.com
Fri May 19 14:30:33 UTC 2017

While some efforts are made to support k/v to store OpenStack
configurations [1] [2] [3], I spent some time this week to investigate
how Puppet modules could still be used to manage data binding, but
push the config into etcd instead of the files.

A containerized TripleO environment only use Puppet modules to manage
configuration file (and some other bits, but unrelated to $topic). The
configuration management is done in 2 steps: the data binding (exposed
to the end-user) and writing the configuration somewhere (in files
right now e.g. /etc/keystone/keystone.conf). As we are moving to etcd
to store configuration, we still need to maintain a stable interface
for data binding until we figure out the replacement. In other words,
we haven't found yet how we could replace Hiera to bind Heat
parameters into actual OpenStack parameters consumed by the services.

I've been thinking of a transition where we would use etcd to store
configs but we would still use Puppet and Hiera to handle data binding
and push the config into etcd. I think it would make the transition to
etcd smoother since we wouldn't change any logic in parameters and it
would give us more time to find a way to manage the future tool that
will actually push the configuration directly from the interface
(instead of using Puppet). Puppet would still be run during the
TripleO deployment but it wouldn't write any configuration file.
Instead, it would push the config into etcd before or during deploying

    |    TripleO Interface           |
    | (Heat Templates, UI, etc) |
        | Puppet / Hiera |
                | etcd |

I started this WIP work:

It's a first draft of what could be done in puppet-openstacklib to use
etcd as a configuration store backend, instead of configuration file.
During the investigation, I found some limitations to ruby-etcdv3 and
also found out that the openstack_config ruby provider would certainly
require some refacto to be used by etcd backend (a lot of bits are
written for inifile provider).

I'm looking for early feedback on this work, and also potential
contributors willing to help in this effort.


[1] https://etherpad.openstack.org/p/BOS-forum-future-of-configuration-management
[2] https://review.openstack.org/#/c/466109/
[3] https://review.openstack.org/#/c/454897
Emilien Macchi

More information about the OpenStack-dev mailing list