<div dir="ltr">On 27 June 2013 23:53, Joe Landman <span dir="ltr"><<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.com</a>></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>
><br>
> For shuffling data around and the equivalent of what Salt's original<br>
> 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>
> use them with canned lists of hosts (generated by cf-engine for this<br>
> purpose eg: all hosts of type X), with ssh keys etc. I suspect they are<br>
> slower and and perhaps less "something" (scalable perhaps? we are a<br>
> relatively small site in HPC terms) than Salt's ZMQ based approach. But<br>
> they've been good enough for what we'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'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'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't something you only need to use if you have webscale sites. IMHO it'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 "tool" 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">
> I would suggest some caution when approaching Salt - which we did when<br>
> we were considering what to do after chef. While Salt seems to be an<br>
> exceptional approach to "do a bunch of things on a bunch of hosts," AND<br>
> it is in python (win!), it does seem that the configuration management<br>
<br>
</div>... some of us don't quite see language of implementation as a win or<br>
loss, with a notable exception (java)<br>
<div class="im"><br>
> part is an add-on and/or afterthought. Yes - configuration management<br>
> does involve lots of doing lots of things on lots of hosts. But<br>
> cf-engine is now in it's third iteration of "what does that _mean_ in<br>
> real terms - with tons of different configuration 'languages', files,<br>
> daemons, restart services etc.. even only on Linux?"<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 "install OS, run configure scripts<br>
on it" section of startup, would you?  This isn't a sales pitch, its a<br>
genuine question.<br></blockquote><div><br></div><div>I don't understand your question, how can you eliminate configuration? At some point you have to tell the system what it'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'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'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 "stateless OS" 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 <<a href="mailto:jonathan.barber@gmail.com">jonathan.barber@gmail.com</a>>
</div></div>