On Tue, May 28, 2019 at 10:50 AM Donny Davis <donny@fortnebula.com> wrote:
Wouldn't it be easier just to use OSA once things get past laying down the OS and the relevant configs for the network interfaces. It seems like building it all in ansible has already been done, and much of the work could be used. I understand that both have different opinions on how to deploy openstack, but it would lower the lift in getting an ansible based deployment operational much sooner.
It's not easier because we then have to translate our current puppet/hiera configuration into their ansible vars. We're trying to come up with a generic construct that still allows end users to override specific configuration items without having to continue to use puppet to lay down the configuration. The proposed format maps more to what oslo.config needs and less about the implementation of what is ultimately doing the configuration writing. We still also need to support backwards compatibility to a certain extent. We unfortunately cannot just drop in OSA because we have our own opinionated assumptions about how we do containers/orchestration so for this conversation it's just about simplifying or reorganizing the configuration bits. In the longer term if we decided that we wanted to stop using configuration files and switch to "something else", we wouldn't then need to figure out how to rip out OSA (if they don't support the "something else"). Thanks, -Alex
On Tue, May 28, 2019 at 12:17 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, May 27, 2019, at 4:36 PM, Emilien Macchi wrote:
(First of all: thanks to Alex Schultz who initiated the discussion during the last PTG).
Context: With the containerization of the services in TripleO, our usage of Puppet is pretty much limited to laying down parameters into configuration files. Our long term goal is to reduce our number of tools in TripleO and converge toward more Ansible and we are currently investigating how to make it happen for Configuration Management, in a backward compatible and non-disruptive way.
Problems: - Our current interface to configure things is very tight to Puppet and Hiera, which would make it complicated to bind it with Hiera. Some of us have tried (to create some Hiera module in Ansible) but clearly this is not the path we want to take as far I know. - We don't use the logic (generally) in the Puppet modules and again only care about the configuration providers (in puppet-openstacklib and for some services, templates files), so the Puppet modules now do too much for what we need in TripleO.
snip
I'm not sure if this is useful but what the Infra team did was to transplant all of its hiera data into /etc/ansible/hosts/host_vars and /etc/ansible/hosts/group_vars. Then we updated our puppetry to pull hiera data out of there. This means that puppet and ansible read the same data sources which has made transitioning things easy for us.
Though I think the ansible-role-puppet role copies hiera data sources from /etc/ansible/hosts to the appropriate puppet hiera location on the remote source. But you mostly don't have to think about that and there is no double accounting from an ops perspective.
Clark