[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