--=-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@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--