Supporting Ansible as another tool for ovirt infra mgmt

[Barak Korren]

On 3 April 2016 at 10:21, Eyal Edri <eedri at redhat.com> wrote:
> I'd like to ask the team what do you think on $subject, in terms of pros &
> cons.
>
> As you all know we have been using puppet to manage our production infra
> (user access, server configuration,etc... ).
>
> Recently we started looking into migrating our mailman instance into new
> hyper-kitty instance to run on the oVirt DC in PHX.
> It seems that there is no true puppet classes available to install/manage
> mailman3 but there is an Ansible playbook used / written by fedora to deploy
> their instance.
> So the question is should we start using/supporting Ansible as another tool
> to manage our infra and leverage existing playbooks out there to reduce work
> on migration of new services?
> I'm not suggesting to migrate all puppet code into Ansible, but to allow
> using Ansible when it make sense.
>
> Here is what I had in mind with regards to pro/cons:
> Pros
>
> Saving time writing puppet classes for services (if Ansible playbook exists)
> Bringing in new infra members which are interested in Ansbile (maybe publish
> the team in the relevant communities)
>
>
> Cons:
>
> Another tool to support/maintain
> No real support to manage in foreman as we do for puppet (for sure not in
> our old version)
>
>
>
> I'd love to hear your thoughts about it.
>

As I've already stated elsewhere Ansible is interesting for a number
of reasons, but a dual-tool scenario will not be welcome IMO.

There is also a lage question of the possibility of replacing Puppet
with Ansible. Puppet is a continues configuration-management system
that monitors servers for configuration drift and repairs it
(deploying missing components in the process), to do that it supports
a declarative language and a master/slave-agent architecture.
The common Ansible usage scenario OTOH seems to be AFAIK a
developer/op launching a deployment task from his laptop. For that
Ansible supports a more imperative syntax and an SSH-based agent-less
architecture.

IMO, for long-running on-premise infrastructure (Not ad-hoc in "the
cloud") which is what oVirt has and what what it targets, the drift
monitoring approach is more suitable.

Now, I've hared that that Ansible could also be deployed with agents
and a central server (Tower? Foreman? something else?), but I'm not
sure how mature that deployment scenario is right now, nor wither
existing Ansible code fits that scenario.


-- 
Barak Korren
bkorren at redhat.com
RHEV-CI Team