<div dir="ltr">I think another point for consideration is the Puppet+Foreman support, foreman doesn't support puppet 4 yet[1], but f23 runs only with puppet >4 agents, if that doesn't get fixed soon and we can't upgrade puppet to 4, we will hit a big problem when we need to migrate more slaves to f23.<br><br>[1] <a href="http://projects.theforeman.org/issues/8447">http://projects.theforeman.org/issues/8447</a><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 3, 2016 at 10:42 AM, Barak Korren <span dir="ltr"><<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 3 April 2016 at 10:21, Eyal Edri <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br>
> I'd like to ask the team what do you think on $subject, in terms of pros &<br>
> cons.<br>
><br>
> As you all know we have been using puppet to manage our production infra<br>
> (user access, server configuration,etc... ).<br>
><br>
> Recently we started looking into migrating our mailman instance into new<br>
> hyper-kitty instance to run on the oVirt DC in PHX.<br>
> It seems that there is no true puppet classes available to install/manage<br>
> mailman3 but there is an Ansible playbook used / written by fedora to deploy<br>
> their instance.<br>
> So the question is should we start using/supporting Ansible as another tool<br>
> to manage our infra and leverage existing playbooks out there to reduce work<br>
> on migration of new services?<br>
> I'm not suggesting to migrate all puppet code into Ansible, but to allow<br>
> using Ansible when it make sense.<br>
><br>
> Here is what I had in mind with regards to pro/cons:<br>
> Pros<br>
><br>
> Saving time writing puppet classes for services (if Ansible playbook exists)<br>
> Bringing in new infra members which are interested in Ansbile (maybe publish<br>
> the team in the relevant communities)<br>
><br>
><br>
> Cons:<br>
><br>
> Another tool to support/maintain<br>
> No real support to manage in foreman as we do for puppet (for sure not in<br>
> our old version)<br>
><br>
><br>
><br>
> I'd love to hear your thoughts about it.<br>
><br>
<br>
</div></div>As I've already stated elsewhere Ansible is interesting for a number<br>
of reasons, but a dual-tool scenario will not be welcome IMO.<br>
<br>
There is also a lage question of the possibility of replacing Puppet<br>
with Ansible. Puppet is a continues configuration-management system<br>
that monitors servers for configuration drift and repairs it<br>
(deploying missing components in the process), to do that it supports<br>
a declarative language and a master/slave-agent architecture.<br>
The common Ansible usage scenario OTOH seems to be AFAIK a<br>
developer/op launching a deployment task from his laptop. For that<br>
Ansible supports a more imperative syntax and an SSH-based agent-less<br>
architecture.<br>
<br>
IMO, for long-running on-premise infrastructure (Not ad-hoc in "the<br>
cloud") which is what oVirt has and what what it targets, the drift<br>
monitoring approach is more suitable.<br>
<br>
Now, I've hared that that Ansible could also be deployed with agents<br>
and a central server (Tower? Foreman? something else?), but I'm not<br>
sure how mature that deployment scenario is right now, nor wither<br>
existing Ansible code fits that scenario.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Barak Korren<br>
<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a><br>
RHEV-CI Team<br>
_______________________________________________<br>
Infra mailing list<br>
<a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
</font></span></blockquote></div><br></div>