On Tue, Jan 5, 2016 at 2:52 PM, Niels de Vos <nde...@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@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-infra _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org http://www.gluster.org/mailman/listinfo/gluster-infra