<div dir="ltr">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.  <div><br></div><div><br><div><br></div><div> </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 12:17 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, May 27, 2019, at 4:36 PM, Emilien Macchi wrote:<br>
> (First of all: thanks to Alex Schultz who initiated the discussion <br>
> during the last PTG).<br>
> <br>
> Context:<br>
> With the containerization of the services in TripleO, our usage of <br>
> Puppet is pretty much limited to laying down parameters into <br>
> configuration files.<br>
> Our long term goal is to reduce our number of tools in TripleO and <br>
> converge toward more Ansible and we are currently investigating how to <br>
> make it happen for Configuration Management, in a backward compatible <br>
> and non-disruptive way.<br>
> <br>
> Problems:<br>
> - Our current interface to configure things is very tight to Puppet and <br>
> Hiera, which would make it complicated to bind it with Hiera. Some of <br>
> us have tried (to create some Hiera module in Ansible) but clearly this <br>
> is not the path we want to take as far I know.<br>
> - We don't use the logic (generally) in the Puppet modules and again <br>
> only care about the configuration providers (in puppet-openstacklib and <br>
> for some services, templates files), so the Puppet modules now do too <br>
> much for what we need in TripleO.<br>
> <br>
<br>
snip<br>
<br>
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.<br>
<br>
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.<br>
<br>
Clark<br>
<br>
</blockquote></div>