[Gluster-infra] Switching from salt to ansible ?

[Kaushal M]

On Tue, Jan 5, 2016 at 2:52 PM, Niels de Vos <ndevos at redhat.com> wrote:
> 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).

Salt is also a Python based tool. You were probably thinking about
Puppet or Chef. :)

>
> Niels
>
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra