<div dir="ltr">On 28 June 2013 21:56, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/28/2013 04:45 AM, Jonathan Barber wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 27 June 2013 23:53, Joe Landman <<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.<u></u>com</a><br></div><div class="im">
<mailto:<a href="mailto:landman@scalableinformatics.com" target="_blank">landman@<u></u>scalableinformatics.com</a>>> wrote:<br>
<br>
    On 06/25/2013 04:55 PM, Paul English wrote:<br><br></div></blockquote></blockquote><div style>[snip]</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
The problem with SSH based approaches is when you have failed nodes -<br>
normally they cause the entire command to hang until the attempted<br>
connection times out.<br>
</div></blockquote>
<br>
This isn't an issue for things like pdsh. Also theres a nifty utility called whatsup that handles all this for you.  It makes determining what is up, well, fairly painless.</blockquote><div><br></div><div style>I will investigate pdsh to see how it avoids some of the problems I described in my other response.<br>
</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The message based systems typically don't have this problem because they<br>
use a pub-sub model where the clients subscribe to hear the commands<br>
from the server. If the client is down, the server doesn't wait on them<br>
<br>
</blockquote>
<br></div>
This isn't so much of an issue.</blockquote><div><br></div><div style><shrugs/> It's always been the problem I've had when trying to run commands over a large number of hosts.</div><div style><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[snip]<br>
<br>
<br>
    Honestly configuration management is largely a moot point for<br>
    image/remote boot, and an annoying necessity for local boot/management.<br>
<br>
<br>
I would like to point out that configuration management isn't something<br>
you only need to use if you have webscale sites. IMHO it's useful<br>
whenever you need to manage some configuration - including the<br>
configuration of binary images. How do you manage the creation of that<br>
image if not with some kind of configuration management tool (even if<br>
your "tool" is a set of shell scripts)?<br>
</blockquote>
<br></div>
I think you are conflating too many things here.<br>
<br>
1) image management:  This is for OS config as you are talking about above.  Configuration management is usually associated with this to some degree, this is where yum and many other tools come into play at a low level.<br>
</blockquote><div><br></div><div style>By other tools do you mean tools such as apt?</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) configuration management atop a base image.  Many distros try to mix these together, and often do a terrible job of it (rpm.saves anyone?).</blockquote><div><br></div><div style>For me, this is a distinction based upon tools and it suggests that we are talking about different things when we refer to configuration management.</div>
<div style><br></div><div style>I would say that configuration management is the process by which you reach the final operating system state, and therefore includes the "base OS" (or JEOS to use a particularly hideous acronym) configuration (disk layout, network configuration [bonds], etc.) to provide a platform to bootstrap the rest of the system onto and then  installing additional software and configuring it all via script/puppet/chef/whatever and dpkg/rpm/tar or apt/yum.</div>
<div style><br></div><div style>So, moving the configuration to the point of installation (for me) doesn't stop it from being configuration. Indeed, if your root is via NFS or a binary image, then that configuration is still being done - just at a single point instead of over many machines.<br>
</div><div style><br></div><div style>Please note that I'm not saying one approach is superior to the other, but I would argue there is configuration management going on either way.</div><div style><br></div><div style>
[snip]</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    A big chunk of what you write about are best handled by a monitoring<br>
    system as compared to a configuration management system.<br>
<br>
<br>
Yes, monitoring is not the same as configuration.<br>
</blockquote>
<br></div>
I think you may have not grasped what I wrote.</blockquote><div><br></div><div style>Perhaps not, would you be kind enough to explain?<br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
<br>
<br>
I don't understand your question, how can you eliminate configuration?<br>
At some point you have to tell the system what it's supposed to do.<br>
</blockquote>
<br></div>
Its done once.  Then you don't have to install it again.  Its installed.  Its done.<div class="HOEnZb"><div class="h5"><br>
<br></div></div></blockquote><div style>And if you have to change it afterwards, how do you manage the change in configuration? Presumably you have to apply the changes to some base image via some process (even if it's just a script or manual alteration with $EDITOR) and then push the changes out to the nodes? If so, then I would still call this configuration (management).<br>
</div><div style><br></div><div style>Cheers <br></div><div style><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Joseph Landman, Ph.D<br>
Founder and CEO<br>
Scalable Informatics, Inc.<br>
email: <a href="mailto:landman@scalableinformatics.com" target="_blank">landman@scalableinformatics.<u></u>com</a><br>
web  : <a href="http://scalableinformatics.com" target="_blank">http://scalableinformatics.com</a><br>
       <a href="http://scalableinformatics.com/siflash" target="_blank">http://scalableinformatics.<u></u>com/siflash</a><br>
phone: <a href="tel:%2B1%20734%20786%208423%20x121" value="+17347868423" target="_blank">+1 734 786 8423 x121</a><br>
fax  : <a href="tel:%2B1%20866%20888%203112" value="+18668883112" target="_blank">+1 866 888 3112</a><br>
cell : <a href="tel:%2B1%20734%20612%204615" value="+17346124615" target="_blank">+1 734 612 4615</a><br>
</div></div></div></div><br><br clear="all"><div><br></div>-- <br>Jonathan Barber <<a href="mailto:jonathan.barber@gmail.com">jonathan.barber@gmail.com</a>>
</div></div>