<div dir="ltr">Hello All.<div><br></div><div>I did not follow the recent Ansible developments, but at the time when I researched it looked like a fancy SSH playbook library (a "better" fabric) rather than "configuration management" system. This is not always bad depending on what we want.</div><div><br></div><div>1. The strongest benefit of the Ansible is that it is easy to start using it for anybody knowing Python, same way as fabric it is essentially SSH client with imperative Python code that sequentially execute the actions. They claim the concept of idempotence, but it is not desired state system like Puppet, so instead of declaring a desired state and letting the computer do the magic, you just list the steps to execute it imperatively and if done right several runs won't break anything due to idempotence.</div><div><br></div><div>2. Also it is push approach and uses SSH so unless we want to execute it from personal laptops as with fabric we will have to have a central server with root SSH access to all our Ansible-managed servers where we can execute it. There were orchestration tools such as Tower, but they were not open source and looks like are not open source yet. Maybe there is something other I am not aware about, please let me know.</div><div><br></div><div>Given those two items I really not sure we can use Puppet and Ansible systems together as configuration management tools. The only ways to use them together that I see are: </div><div><br></div><div>1. Use Ansible as a fabric replacement - to run things ad hoc (e.g. running yum upgrade openssl) This does not work for mailman3 as it will be "unpuppetized" in our terms.</div><div>2. Use Ansible only on part of the hosts. This works for mailman3, but for us those host will leave as "unpuppetized" again plus we have to come up with infra to support those hosts deployment due to luck of foreman support. In addition we have to develop a way to transfer our users (puppet classes + hiera now) to those servers that complicates deployment even more.</div><div><br></div><div>However it is not all or nothing problem, so the short term solution I would propose and agree with:</div><div><br></div><div>It is ok to use Ansible for a limited set of hosts because it is easier for people to learn and use it and hence - contribute deployment instructions to us. But I would treat those hosts as "unpuppetized" on our side. The motivation for that is that well, we do have a bunch of unpuppetized hosts and obviously puppetizing everything is not a one day effort deal. Myabe it should not block PHX migration. If somebody wants to use Ansible instead of manually configuring hosts over SSH it is great. The host is still unpuppetzied, but same way we have deployment instructions as a playbook in SCM. And to get our users on the host we can use foreman + puppet infra classes the same way we do for manually installed servers. So the requirement for PHX migration than will be relaxed: deployment should be reproducible + the host should support our infra tools such as foreman and user classes.</div><div><br></div><div>Anton.</div><div><br></div><div><br></div><div><div class="gmail_extra">-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><div>Anton Marchukov<br>Senior Software Engineer - <span><span><font color="#888888"><span><span><font color="#888888"><span><span><font color="#888888">RHEV CI - </font></span></span></font></span></span>Red Hat</font></span></span><br><br></div></font></span></div></div></div></div>
</div></div></div>