--=-otveoOJhLjC/wERAXH+D
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le dimanche 03 avril 2016 =C3=A0 10:42 +0300, Barak Korren a =C3=A9crit :
On 3 April 2016 at 10:21, Eyal Edri <eedri(a)redhat.com> wrote:
> I'd like to ask the team what do you think on $subject, in terms of pro=
s
&
> cons.
>
> As you all know we have been using puppet to manage our production infr=
a
> (user access, server configuration,etc... ).
>
> Recently we started looking into migrating our mailman instance into ne=
w
> hyper-kitty instance to run on the oVirt DC in PHX.
> It seems that there is no true puppet classes available to install/mana=
ge
> mailman3 but there is an Ansible playbook used / written by
fedora to d=
eploy
> 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 allo=
w
> 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 ex=
ists)
> Bringing in new infra members which are interested in Ansbile
(maybe pu=
blish
> 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.
>
=20
As I've already stated elsewhere Ansible is interesting for a number
of reasons, but a dual-tool scenario will not be welcome IMO.
=20
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.
=20
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.
=20
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.=20
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.
--=20
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
--=-otveoOJhLjC/wERAXH+D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJXAqmgAAoJEE89Wa+PrSK9AL0P/27lDqMRRvBQoqKe1g/Psop6
bznlMUuwVv5fipf/GxuoZPhuB68iSpIZYlCZqVijzAG5lSwNGzd4KoGL8TiOuBj1
5rC/tI8QxZdmOPLdC/vU8ojydIz52hzMuirO3DVA6YnTCR1s0Kq2Od1Z2QTPZTcW
A10gPhw7RC5RCgmxnfc97U6+o7iKfob1djgLeFvP/VzpvoC+pOdtuFDy+a1p79Au
ZMMa8CXx48szhZmR4VnCHkzZISsiLV1M6TK9jB3WodRHp5lPrpOwjZCKiyxXWFVE
cElIJxo4s95JA86KXSPixq/m7kj+hYecszE6nuDtdqoC37pmdXrp9oK0yF37WbIR
uj1TIbyzzl8NL9aGJwVop3Q3eSUTMkdk1jZqkb7EdEuQ4QbsyESaZKT6PkcU5m4H
J15YX6rox+qjHa83mSazOqkhBaXzDly1WauOEZsBiqFGsIfV69OD3L90ZaT6lDzQ
02g9vKf+qhORRFkqxLq7PI9xcKD1VWKrmA99uJ0LWWZkvEY/4pQeSBZzgmzk1xqP
BKYDH/AWCFMOBAH7IaCv/y9sMsaIoiZPQ8/p8Pjgo1GMYID58Byi4pEJ/+Ajs4RP
zQ15tDZW8TlC3vi1HOq1OympBYXZuPYVVQIr15i/0TXpMRgNhAVdztTENb9iIuSk
nhyOBFc4v9dYxGkutaMd
=AFNp
-----END PGP SIGNATURE-----
--=-otveoOJhLjC/wERAXH+D--