<div dir="ltr">On 27 June 2013 23:53, Joe Landman <span dir="ltr">&lt;<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 06/25/2013 04:55 PM, Paul English wrote:<br>
<br>
[...]<br>
<div class="im"><br>
&gt;<br>
&gt; For shuffling data around and the equivalent of what Salt&#39;s original<br>
&gt; purpose in life was, we use prsync and pssh. They work very well. We can<br>
<br>
</div>To this day we still prefer pdsh from LANL.  Its (IMO) the best of the<br>
lot, and we leverage it extensively in tiburon.<br>
<div class="im"><br>
<br>
&gt; use them with canned lists of hosts (generated by cf-engine for this<br>
&gt; purpose eg: all hosts of type X), with ssh keys etc. I suspect they are<br>
&gt; slower and and perhaps less &quot;something&quot; (scalable perhaps? we are a<br>
&gt; relatively small site in HPC terms) than Salt&#39;s ZMQ based approach. But<br>
&gt; they&#39;ve been good enough for what we&#39;ve done so far.<br></div></blockquote><div><br></div><div style>The problem with SSH based approaches is when you have failed nodes - normally they cause the entire command to hang until the attempted connection times out.</div>
<div style><br></div><div style>The message based systems typically don&#39;t have this problem because they use a pub-sub model where the clients subscribe to hear the commands from the server. If the client is down, the server doesn&#39;t wait on them</div>
<div style><br></div><div style>[snip]</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Honestly configuration management is largely a moot point for<br>
image/remote boot, and an annoying necessity for local boot/management.<br></blockquote><div><br></div><div style>I would like to point out that configuration management isn&#39;t something you only need to use if you have webscale sites. IMHO it&#39;s useful whenever you need to manage some configuration - including the configuration of binary images. How do you manage the creation of that image if not with some kind of configuration management tool (even if your &quot;tool&quot; is a set of shell scripts)?</div>
<div style><br></div><div style>The configuration problem is independent of the system deployment mechanism.</div><div style><br></div><div style>[snip]</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
&gt; I would suggest some caution when approaching Salt - which we did when<br>
&gt; we were considering what to do after chef. While Salt seems to be an<br>
&gt; exceptional approach to &quot;do a bunch of things on a bunch of hosts,&quot; AND<br>
&gt; it is in python (win!), it does seem that the configuration management<br>
<br>
</div>... some of us don&#39;t quite see language of implementation as a win or<br>
loss, with a notable exception (java)<br>
<div class="im"><br>
&gt; part is an add-on and/or afterthought. Yes - configuration management<br>
&gt; does involve lots of doing lots of things on lots of hosts. But<br>
&gt; cf-engine is now in it&#39;s third iteration of &quot;what does that _mean_ in<br>
&gt; real terms - with tons of different configuration &#39;languages&#39;, files,<br>
&gt; daemons, restart services etc.. even only on Linux?&quot;<br>
<br>
</div>A big chunk of what you write about are best handled by a monitoring<br>
system as compared to a configuration management system.<br></blockquote><div><br></div><div style>Yes, monitoring is not the same as configuration.</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
If you could completely eliminate the &quot;install OS, run configure scripts<br>
on it&quot; section of startup, would you?  This isn&#39;t a sales pitch, its a<br>
genuine question.<br></blockquote><div><br></div><div>I don&#39;t understand your question, how can you eliminate configuration? At some point you have to tell the system what it&#39;s supposed to do.<br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Chef and puppet are popular in some circles.  They handle some things<br>
nicely, though writing python objects as configuration is IMO a broken<br>
design by default.  Ruby is a cool fad-dy language, but debugging it is<br>
... interesting.  Almost as much fun as debugging some other languages.<br></blockquote><div><br></div><div style>I thought languages didn&#39;t matter! :)</div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
At the end of the day, all of these things are about automation, work<br>
reduction, scaling, maintainability.  I am no fan of things that make<br>
maintenance hard(er).  I am a huge fan of positive automation benefits.<br>
  This is why the stateless OS systems scale so well, and are so easy to<br>
maintain.  If you ever have a problem with a unit, you reboot it.  No<br>
reloading required.  Just reboot it.<br></blockquote><div><br></div><div style>I&#39;m in violent agreement. But for me, c<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:16.363636016845703px">onfiguration management tools give you the &quot;stateless OS&quot; as well. Just reboot, install the OS to the point where you get the configuration management tools running, then run the tool to get to the desired state.</span></div>
<div style><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:16.363636016845703px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:16.363636016845703px">The advantage of configuration management tools for me is when you want to (de)compose part of your systems into discrete parts in order to test them.</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:16.363636016845703px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:16.363636016845703px">Cheers</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">
<br>
--<br>
Joseph Landman, Ph.D<br></font></span></blockquote></div><div><br></div>-- <br>Jonathan Barber &lt;<a href="mailto:jonathan.barber@gmail.com">jonathan.barber@gmail.com</a>&gt;
</div></div>