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 containers. +---------------------------------+ | TripleO Interface | | (Heat Templates, UI, etc) | +----------------------------------+ | +----------v--------+ | Puppet / Hiera | +--------------------+ | +--v--+ | etcd | +------+ I started this WIP work: https://review.openstack.org/#/c/466292/ 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. Thanks, [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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev