On Tue, Feb 7, 2012 at 2:36 PM, Craig White <craig.white at ttiltd.com> wrote: > >> >> I'm actually very interested in this, but puppet did not look like the >> right architecture. http://saltstack.org/ might not be quite ready >> for prime time but it looks like a very reasonable design. The python >> dependencies are probably going going to be painful for cross platform >> installs but at least someone on its mail list has it working on >> windows and there are already epel packages. > ---- > a different type of management system. Puppet & Chef are simply about configuration management. So is salt, but scalable, and with the ability to make decisions based on client state in more or less real time. And even though it is mostly or all python now, it really passes around data structures that should allow other languages to be used. It is still in early stages but they claim to have converted some puppet installs easily. > Puppet architecture is pretty awesome - but the puppet master itself can't be a stock CentOS 5.x system because ruby 1.8.5 is too ancient. I suppose you can use Karanbir's ruby-1.8.7 packages (or better yet, enterprise ruby packages) if you insist on running the server on CentOS 5.x. The thing about puppet is that the barrier to entry is rather high - it takes some time before you get to something useful whereas Chef is more adept at putting other people's recipes into service fairly quickly. Then again, you will run into barriers with Chef that don't exist with puppet so it seemed that the ramp up investment had long term benefits. Ruby seems like the only thing that might be worse than python in terms of long-term version incompatibilities and installation problems, although python is sort-of a special case on RH systems since the install tools need it. I think something I wrote 20 years ago should still run today, but maybe that's just me. And I didn't see any way to tier puppet masters or keep it from falling over with a large number of clients. -- Les Mikesell lesmikesell at gmail.com