[nycbug-talk] SaltStack and Ansible experience?

[Charles Sprickman]

On Jul 25, 2013, at 6:49 PM, Pete Wright wrote:

> On 07/25/13 15:43, Charles Sprickman wrote:
>> While looking through the wikipedia list of configuration management software[1], I noticed a few new entrants that appear to have some momentum, Ansible[2] and SaltStack[3].  Both appear to have a fair amount of support for the *BSDs.  Both are python based.
>> 
>> For example, looking at SaltStack's list of modules[4], I see support for lots of FreeBSD features: using pkgng (like full support - upgrading a package, fetching current package options, making a backup of an installed package), poudriere (trigger a bulk build, list/create jails and ports trees), and jails.
>> 
>> Anyone here use either of these?  Ideally I'd like something a bit lighter, but SaltStack is intriguing so far.  I also need to see what Puppet currently looks like, but the few BSD-centric reviews I've seen of SaltStack and Ansible both note that support for at least FreeBSD is better than in Puppet-land and that both projects are happy to take patches.
>> 
> 
> I am a pretty big fan of Ansible - and the primary dev behind it was also they guy responsible for cobbler and func (and worked at puppetlabs in a key position for a while as well).
> 
> i've been a long time user of cobbler and func in small and *very* large environments and have been quite happy with the quality of code and its extensibility.  ansible seems to have the same DNA and community that was built around cobbler, so i strongly suggest giving it a serious look.

I've got both running in a small set of VMs.  I'm just doing basics and running things by hand, but I have to say both Ansible and SaltStack seem very nice.  Initial setup once you get past some of the jargon was easy with both. As many Ansible  users noted, getting it to a point where you can copy a few files or restart services in an ad-hoc manner is easy, and SaltStack is equally simple (even though it requires a daemon, it's basically just python and 3-4 python deps).

I think either would work for me.  Which is making the final choice a bit harder.  I'm going to keep pushing through both in this little test setup.

A few things I've noticed so far:

-Salt has more modules that look like huge time savers (why write your own routine to handle working with something like jails or pkgng when someone else already has), and seems to have more stuff for the *BSDs.  This has no impact on the really basic stuff, but something to think about as you want to do more complex automation.
-Salt had more hiccups in the initial install and a few things that seemed a bit odd - the zfs module tries to run "zfs help" on the managed host to figure out what flags the 'zfs' command will accept.  The FreeBSD version of 'zfs' lacks the 'help' switch; additionally if you're on a non-zfs box, invoking 'zfs' will load the module.  A recent pull from someone outside the project brought in this behavior and looking at the comments on github around that pull kind of left me thinking the barrier to entry for contributors might be a bit low.
-Salt spews more non-fatal errors in normal usage (at least on FreeBSD with Python 2.7)
-Both projects have succumbed to that sort of cutesy way of creating their own vocabularies, which annoys me as I feel it makes communicating concepts to new users more difficult.  Ansible has less goofy names for things.
-I have not used Puppet, but in reading up on both Salt and Ansible I'm finding everyone complains about Puppet not allowing you to order your actions.  If that's the case, that's a good enough reason for me to pull Puppet out of the running.

Even SaltStack is giving me a few reasons to worry, the larger selection of useful modules is tipping me a bit.  Next week I may have changed my mind again though…

Thanks for all the input, it's good to see that even if they've been stealth, there are a number of Ansible users here.

Charles

> -p
> 
> 
> -- 
> Pete Wright
> pete at nomadlogic.org
> twitter => @nomadlogicLA
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk