[Gluster-infra] Switching from salt to ansible ?

[Niels de Vos]

On Mon, Jan 04, 2016 at 05:27:10PM +0100, Michael Scherer wrote:
> 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). 

Many of us are more familiar with Ansible than Salt. It'll be easier to
get contributions from developers when Ansible is used.

> - 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.

And can ask the Fedora sysadmins for help/ideas, or discuss the general
approach of a role/task. If something in our Ansible doesn't work well
enough, they might be able to share their thoughts. Fedora Infra is
interested in Gluster and they would surely assist with some bits in
return for our help ;-)

> 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.

Having ssh running, or the salt-minion, does not make much of a
difference to me.

> - 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)

Or (a dedicated ansible user and) use sudo? Might make auditing a little
easier. I think its even possible to use sshd/Match on a username and
only allow certain logins from selected sources (like a management
server).

> and maybe other I didn't think of.
> 
> Any opinions ?

I prefer the move to Ansible, it would allow me to contribute changes
without learning Salt. Fixing/improving Ansible (in Python) is also
something that I can do, but I'll stay away from patching Salt (in
Ruby).

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-infra/attachments/20160105/3039ad4f/attachment.sig>