<div dir="ltr">I was directing this at 3O, but didn't want to jump into the middle of the thread. Thanks for helping to clarify. <div><br></div><div>~/D</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 12:48 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 Tue, May 28, 2019, at 9:40 AM, Donny Davis wrote:<br>
> Wouldn't it be easier just to use OSA once things get past laying down <br>
> the OS and the relevant configs for the network interfaces. It seems <br>
> like building it all in ansible has already been done, and much of the <br>
> work could be used. I understand that both have different opinions on <br>
> how to deploy openstack, but it would lower the lift in getting an <br>
> ansible based deployment operational much sooner. <br>
<br>
Note sure if this was directed to my comments about what Infra has done or if you mean to suggest this for Tripleo. In the Infra case we do not deploy openstack. We deploy a ton of software on top of OpenStack so OSA isn't relevant for our uses.<br>
<br>
> <br>
> <br>
> <br>
> <br>
> On Tue, May 28, 2019 at 12:17 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br>
> > 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>
<br>
</blockquote></div>