<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 5:27 AM, Eugen Leitl <span dir="ltr">&lt;<a href="mailto:eugen@leitl.org" target="_blank">eugen@leitl.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<a href="http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/" target="_blank">http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/</a><br>
<br>
A Taste of Salt: Like Puppet, Except It Doesn’t Suck<br><br></blockquote><div><br></div><div style>We are using cf-engine (3) after a relatively brief dalliance with chef. chef was very slow for our purposes, and ruby seems to be a slightly tidier version of perl ie: not very tidy. It seemed to be a constant source of cursing in the IT department.</div>
<div style><br></div><div style>cf-engine has made the IT team very happy.</div><div style><br></div><div style>Overall, I think the approach of using a configuration management system for... configuration management seems to be the way to go. It is a distribution-agnostic approach too. </div>
<div style><br></div><div style>ROCKS served us well for years, but being chained to the CentOS release cycles (plus some additional delay) tended to hamper using newer hardware, along with other problems. And on the whole, it tended to do a somewhat poor and constrained job of what is essentially &#39;configuration management.&#39; Do we really want/need the master node to be a router to the rest of the network? Well.. sometimes not. Do we really want/need the master node to be the authoritative DHCP and DNS server for the cluster nodes? Maybe..</div>
<div style>etc etc.</div><div style><br></div><div style>For shuffling data around and the equivalent of what Salt&#39;s original purpose in life was, we use prsync and pssh. They work very well. We can use them with canned lists of hosts (generated by cf-engine for this purpose eg: all hosts of type X), with ssh keys etc. I suspect they are slower and and perhaps less &quot;something&quot; (scalable perhaps? we are a relatively small site in HPC terms) than Salt&#39;s ZMQ based approach. But they&#39;ve been good enough for what we&#39;ve done so far. </div>
<div style><br></div><div style>I would suggest some caution when approaching Salt - which we did when we were considering what to do after chef. While Salt seems to be an exceptional approach to &quot;do a bunch of things on a bunch of hosts,&quot; AND it is in python (win!), it does seem that the configuration management part is an add-on and/or afterthought. Yes - configuration management does involve lots of doing lots of things on lots of hosts. But cf-engine is now in it&#39;s third iteration of &quot;what does that _mean_ in real terms - with tons of different configuration &#39;languages&#39;, files, daemons, restart services etc.. even only on Linux?&quot;</div>
<div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style> <br></div></div></div></div>