Supporting Ansible as another tool for ovirt infra mgmt

[Michael Scherer]

Le dimanche 03 avril 2016 à 10:42 +0300, Barak Korren a écrit :
> 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.

So in my case, I do prefer the configuration drift stuff, but I just use
cron to make it converge if it drift with ansible. 

Also, while I like the whole concept of configuration converging,
servers usually do not go out of convergence by themself, so if the
sysadmins do not change it, there isn't less pressure to make it
converge.

So far, what i do is that each push a on specific server trigger a
ansible run, restricted to the server that should be impacted. This is
either done with ssh (for manageiq.org), or using saltstack bus (for
gluster.org, historical reason), or I also do have cron + local run of
ansible (for theopensourceway.org).

So while most people likely use it to deploy from laptop, that's kinda
not how I envision, even in the cloud.


-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160404/3122b1ba/attachment.sig>