[Gluster-infra] Switching from salt to ansible ?
Michael Scherer
mscherer at redhat.com
Mon Jan 4 16:27:10 UTC 2016
Hi,
so over the holidays, I was pondering on moving to ansible from salt.
So the reasons are numerous:
- I am personally much more efficient with ansible than with salt
(despite using salt for 1 year). While the 2 tools do the same basic
stuff, there is always some difference (like user vs owner), and there
is a totally different philosophy when it come to multiple servers
orchestration (one example is how I do deploy freeipa on salt vs
ansible).
- Since I use ansible for most others projects, I do already have a few
roles for most of the thing I want to deploy (freeipa, nagios, etc), and
adding features on them and then again on salt is not very efficient.
- One of the initial reasons to choose salt was a tiny margin of people
who know it in the community, vs ansible. I suspect this is no longer
valid. For example, the vagrant image for developper is made using
ansible, and I know a few people in the dev community who use ansible. I
still think no one grok salt.
- Another of the reason of using salt vs ansible is that salt was much
faster to apply configuration, especially if done on git commit. While
that's true, I managed to make it good enough on manageiq.org using
smart post-commit hook, and salt is getting also slower the more stuff
we add to configuration.
- salt in epel is still using a old version ( for dependencies reasons
). While this is working well enough, it make contributing quite
difficult, and prevent using some new features that are needed.
- having a client/server model is something that caused trouble with
puppet when they decided to support only 1 version of ruby (around the
ruby 2.0 time frame). And given the transition of python2 and 3 is
happening right now in Fedora, I foresee this might be the same kind of
issue for salt.
- Fedora is using ansible, and while we can't reuse their code that
much, we can at least take it and adapt.
Now, there is a few downsides:
- it mean rewriting most of the stuff we already have
- it mean that we depend on sshd to be running. IE, if we screwed ssh
config (happened in the past), we can't just use salt to fix it.
- it also mean that we will have a ssh key to connect as root on a
server, and i am not that confortable with the idea (provided that we
use the regular method of using ansible, ie push based)
and maybe other I didn't think of.
Any opinions ?
--
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://www.gluster.org/pipermail/gluster-infra/attachments/20160104/00712c3f/attachment.sig>
More information about the Gluster-infra
mailing list