[Hontano]

I never got on well with either. Puppet was mind-bogglingly slow (even locally without a master), both Chef and Puppet felt overwrought, and I prefer keeping dependencies to a minimum.

Just a pointer for anyone else that doesn't have much love for either: I found myself happy and productive with Salt. Fast, simple, and lets me do what I needed with less Byzantine setup: http://docs.saltstack.org/en/latest/

There's also Salty Vagrant and Salt Cloud for local and remote provisioning.

[VLM]

"I prefer keeping dependencies to a minimum."

The job of an OS not a human admin. "apt-get install puppet" on the clients and "apt-get install puppetmaster" on the puppetmaster. That's about it.

"Puppet was mind-bogglingly slow"

Was it a pause exactly equal to one DNS lookup timeout? The SSL inside puppet used to get all wound up about reverse DNS matching the forward or whatever exactly. You need working DNS to puppet. If DNS is dead you may as well forget debugging puppet until your local DNS is healthy.

Also its possible to do unusual SSL configurations that can make it a bit slow. Vanilla out of the box should be reasonably fast. Starving a virtual image of CPU can make the SSL slow... a virtual 40 MHZ 386 equivalent is not going to do SSL any faster than a physical 40 MHZ 386 used to.

[Hontano]

"The job of an OS not a human admin. "apt-get install puppet" on the clients and "apt-get install puppetmaster" on the puppetmaster. That's about it."

It might be a simple apt-get command, but consider setting up Chef Server. You're suddenly adding the following to your system: Ruby, CouchDB, RabbitMQ, Java, merb-assets, merb-core, merb-helpers, merb-param-protection, merb-slices, thin, solr-jetty. And then maybe libxml-ruby, merb-haml, haml, coderay. (From http://wiki.opscode.com/display/chef/Installing+Chef+Server)

That's a whole heap of stuff and moving parts I wasn't looking for. Compare that to the above mentioned Ansible or cdist on the lightweight end of the spectrum.

[dredmorbius]

What distro are you running that's got current Puppet/Chef releases in its archives?

The story may be better for puppet, but with chef, it's pretty much "off to the racetrack" to get the latest and greatest Ruby, Chef, and other deps installed.

[nodata]

What was slow? The compilation time for the Puppet catalogs, or the run time on the clients?

Compilation is way quicker in 3.0, averages a couple of seconds per node for me. Client side is parallel, not sure how it could be quicker.

[Hontano]

Sorry, I don't recall in particular. It was about a year ago.

It was only a basic setup of a user account, a directory tree, and ufw. It took over a minute for either a first or subsequent run on a clean install of Natty. Considering how much more config I had to add and too little time to dedicate to investigating and speeding it up, I had to put Puppet aside.

Good to know 3.0 is a lot faster. I'll give it another look in future.

[nodata]

So from what you write it sounds like the time it took for Puppet to apply the configuration changes was the problem: to install all the packages you wanted, and then to configure and check them. This always takes time though, this isn't Puppet specific.

[retrogradeorbit]

Came here to comments to post about saltstack. Couldn't agree more. So blindingly fast. I think people who comment that puppet isn't slow just don't know how fast salt is. Tens of thousands of clients polled in just seconds is something puppet just can't approach. I also found not having to learn yet _another_ DSL refreshing.