[Beowulf] anyone using SALT on your clusters?

[Jonathan Barber]

On 27 June 2013 23:53, Joe Landman <landman at scalableinformatics.com> wrote:

> On 06/25/2013 04:55 PM, Paul English wrote:
>
> [...]
>
> >
> > For shuffling data around and the equivalent of what Salt's original
> > purpose in life was, we use prsync and pssh. They work very well. We can
>
> To this day we still prefer pdsh from LANL.  Its (IMO) the best of the
> lot, and we leverage it extensively in tiburon.
>
>
> > 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 "something" (scalable perhaps? we are a
> > relatively small site in HPC terms) than Salt's ZMQ based approach. But
> > they've been good enough for what we've done so far.
>

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.

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

[snip]

>
> Honestly configuration management is largely a moot point for
> image/remote boot, and an annoying necessity for local boot/management.
>

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)?

The configuration problem is independent of the system deployment mechanism.

[snip]

> 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 "do a bunch of things on a bunch of hosts," AND
> > it is in python (win!), it does seem that the configuration management
>
> ... some of us don't quite see language of implementation as a win or
> loss, with a notable exception (java)
>
> > 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's third iteration of "what does that _mean_ in
> > real terms - with tons of different configuration 'languages', files,
> > daemons, restart services etc.. even only on Linux?"
>
> A big chunk of what you write about are best handled by a monitoring
> system as compared to a configuration management system.
>

Yes, monitoring is not the same as configuration.


>
> If you could completely eliminate the "install OS, run configure scripts
> on it" section of startup, would you?  This isn't a sales pitch, its a
> genuine question.
>

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.


> Chef and puppet are popular in some circles.  They handle some things
> nicely, though writing python objects as configuration is IMO a broken
> design by default.  Ruby is a cool fad-dy language, but debugging it is
> ... interesting.  Almost as much fun as debugging some other languages.
>

I thought languages didn't matter! :)


>
> At the end of the day, all of these things are about automation, work
> reduction, scaling, maintainability.  I am no fan of things that make
> maintenance hard(er).  I am a huge fan of positive automation benefits.
>   This is why the stateless OS systems scale so well, and are so easy to
> maintain.  If you ever have a problem with a unit, you reboot it.  No
> reloading required.  Just reboot it.
>

I'm in violent agreement. But for me, configuration 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.

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.

Cheers

>
> --
> Joseph Landman, Ph.D
>

-- 
Jonathan Barber <jonathan.barber at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20130628/aef93048/attachment.html>