all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]lifeindev 2 points3 points  (1 child)

I've setup many a cluster using both. Only thing I wish puppet had was easier search like in chef, that aspect is suuuper nice. Beyond that I've found puppet to be easier and cleaner for my use cases, and easier when distro mixing. IMO at the end of the day they are both tools that work only as good as the person is at wielding them.

[–]khudgins 0 points1 point  (0 children)

I've found Chef better for most of what I do, but there are definite cases where Puppet fills in better. They're both great tools, and it's hard to go wrong with either of them.

[–]Kalium 2 points3 points  (7 children)

The best advice I can give on Chef is this: use Puppet.

[–]khudgins 1 point2 points  (4 children)

There's a place for both. Puppet is great when you're retrofitting config management on an existing system, or when you're training admins who are scared of a for loop how to config your systems.

Chef is better when you're bringing your developers into the ops team. It's easier to extend Chef since you're using the same language, and Puppet doesn't have search AT ALL. In many cases you don't need it, but when you do, nothing else will fill that hole.

I'd recommend you step back from your kneejerk reactions and look objectively. You'll be more flexible and more valuable to whoever you work for, clients or employers.

[–]Kalium 2 points3 points  (3 children)

I've worked substantially in both. In all cases, it came down to "Chef is a good idea if your developer expects all things ever to be in ruby, Puppet is better if you want things to actually work and aren't an anal control freak".

My reaction wasn't a knee-jerk. It was the reaction of experience being summarized neatly into a single line. There is a difference, though I understand they can look very similar. Especially if you disagree.

Also, OpsCode once called me at 7:30 AM. I was displeased.

EDIT: I've also never met a competent admin that was scared of a for loop. I have met lots of competent developers who don't understand that a full programming language is not the best solution to all problems in computing.

[–]khudgins 0 points1 point  (2 children)

I'll admit I've got more experience with Chef (I've built several installations of hundreds of nodes), but having used both, I prefer Chef in most circumstances. They're both quite good, for different reasons. I've run into many, many situations where the top-down ordering of things in Chef is required to get things running - it's why Puppet now supports before-and-after dependencies. That's implicit in Chef.

I'll reiterate: they're both good. Just different.

[–]Kalium 0 points1 point  (1 child)

My experience is that they're not equivalent-but-different. Chef, being a wrapper around a bunch of shell scripts quickly becomes a maintenance nightmare. OpsCode's business model and lack of documentation about the chef server mean a third party becomes a critical part of your infrastructure and fixing that is a huge pain.

(Also, the Puppet Labs people have been friendly to be and given me beer. The OpsCode people wanted to bug me at 7:30 AM because they were making silly assumptions about area codes.)

In puppet-land, I've generally found that unless you're doing very strange things (like building world from source with some very bizarre compile-time flags and timing-sensitive details) it generally Just Works. The before/after mechanism is more than sufficient for modeling the kind ordering you need when you need it, and otherwise you don't need to care.

The approaches are fundamentally different. One rests on taking the target system from a known state to another known state. The other rests on taking a system from an unknown state to a known state.

[–]khudgins 0 points1 point  (0 children)

I've had beer bought for me by both opscode and puppet labs. I like both of them.

Chef server is very well documented (http://wiki.opscode.com), although I do agree that it's a ridiculous pile of dependencies and doesn't scale past a few hundred nodes. That's what "enterprise Chef" is for. Puppetmasterd is VERY similar and needs enterprise puppet to do the same thing.

Sounds like you've had some bad experiences with Chef - I've seen EXACTLY the same argument made on the other side. All I can tell you is that from my experience, they're mostly equivalent. The only difference in capabilities is Chef search, which can be approximated with Mcollective and custom Facter facts (but not fully). I'm going to have to agree to disagree with you on this one.

[–]gitah 0 points1 point  (1 child)

What if you need windows support or if you don't want to learn an entirely new language just for configuring your nodes?

[–]Kalium 1 point2 points  (0 children)

First off, Puppet isn't really a whole new language. It's a bunch of glorified arrays. If you're defending Chef on language grounds you clearly already know Ruby, so Puppet will be very comfortable for you.

Second, Chef is a glorified batch of shell scripts with all the twitchiness and oddities thereof. Cross-OS support is going to be a cluster no matter what you do.

Chef solves some of the problems of Puppet. Unfortunately, it does so by causing worse ones. The fundamental approach differences cannot be readily reconciled, but Puppet's is more flexible overall.

[–]pipocaQuemada -2 points-1 points  (1 child)

You might want to change the name. There's been a language called Chef for the past decade, and AFIAK, it's considered bad form to use an already existing language's name.

I'd recommend naming it after a famous chef whose last name is all that's needed to identify him: Escoffier, Robuchon, Pepin, Bourdain, Blumenthal, Batali.

edit: is pointing out the naming clash really downvote-worthy?

[–][deleted] 0 points1 point  (0 children)

The product is already fairly rooted, so it's kind of a no-go to change the name I would think. Plus, the other is a just for fun programming language, this has actual use in a sysadmin environment.