Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puppet vs Chef, Fight

devopsanywhere.blogspot.com

Post reply on HN
Print view View original

21–30 of 109 posts

Re: Puppet vs Chef, Fight

#21

Post by [deleted] »

rubyrescue wrote: post #14
techscruggs wrote: post #4

I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server. Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 10…

Kevin Smith gave a talk a few weeks ago in Atlanta, that they're slowly removing those dependencies. He did specifically mention removing Couch and didn't mention Merb but based on his approach to deciding to remove Couch I'm sure he's going to address it.

[deleted]

Re: Puppet vs Chef, Fight

#22

Post by davnola »

techscruggs wrote: post #4

I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server. Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 10…

It's not the core, it's just the webui. I never use it, choosing in preference the REPL and the `knife` command.

Re: Puppet vs Chef, Fight

#23

Post by olegp »

burgerbrain wrote: post #15
olegp wrote: post #7

Does anybody else think there's room for a lightweight alternative to these two projects written in server side JavaScript?

Why should the language matter? Functionality should be the feature.

JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature.

From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven architecture and c) run multiple downloads or other setup related tasks in parallel.

Re: Puppet vs Chef, Fight

#24

Post by bryanwb »

spez wrote: post #18

Our experience with puppet at Hipmunk was dreadful. The configuration language is clearly designed to cause maximum pain. We have since switch to Fabric http://fabfile.org , and are much happier.

I have written tons of fabfiles and Fabric is a great project. However it isn't intended to managed system state. It is great for code deployment but not suited to configuration management.

Re: Puppet vs Chef, Fight

#25

Post by Woost »

techscruggs wrote: post #9
socratic wrote: post #5

Am I totally missing some obvious Chef documentation? The entirety of the documentation when I last looked seemed to be the wiki + the one 50-page O'Reilly book. I ended up literally printing out the wiki. (And the wiki seemed to be in a state of pretty extreme flux and/or disagreement with what blog posts suggested was best practice.) The business model of the companies promoting Puppet and Chef seems to be to charg…

I was a bit confused by the "excellent reference documentation" regarding Chef, as well. The documentation I have read has been out of sync, occasionally contradictory piece-meal. I have yet to find anything more useful than just reading recipes. I wonder if the author knows of resources other than that book and the wiki.

The chef irc channel can be helpful (http://wiki.opscode.com/display/chef/IRC)

Re: Puppet vs Chef, Fight

#26

Post by techscruggs »

davnola wrote: post #22
techscruggs wrote: post #4

I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server. Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 10…

It's not the core, it's just the webui. I never use it, choosing in preference the REPL and the `knife` command.

Good to know, that does make my concern significantly more trivial.

Re: Puppet vs Chef, Fight

#27

Post by techscruggs »

Woost wrote: post #20
techscruggs wrote: post #4

I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server. Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 10…

Just as a warning: If you/anyone decides to self host a chef server, you have to get the chef-server cookbook (or your couchdb will never get compacted) and you can't be running ruby 1.9.1 (or the server will have ~1 week uptime before crashing randomly) As for the core being built on merb. I don't really notice it. You'll probably never have a reason to go into the chef-server internals to change something. Besides…

What version of chef server are you using? It appears to have been fixed a while again: http://tickets.opscode.com/browse/CHEF-489 .

Perhaps your issue is not tied to your ruby version: http://tickets.opscode.com/browse/CHEF-920

Re: Puppet vs Chef, Fight

#28

Post by agj »

maratd wrote: post #2

> If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it. Why? I prefer to simply write my own bash deployment scripts. Seems easier.

I prefer bash scripting for this as well. With a small ops team, pushing for adoption of Puppet or Chef, and definitely cfengine, can be difficult. However having a backbone for running the scripts and providing reporting is a great benefit.

I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though.

1: http://code.google.com/p/slack/

2: http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm

Re: Puppet vs Chef, Fight

#29

Post by count »

olegp wrote: post #23
burgerbrain wrote: post #15

Earlier quoted context omitted.

Why should the language matter? Functionality should be the feature.

JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature. From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven archite…

What javascript engine ships on a linux server today? Ruby and Python are both packaged in by default on basically everything, V8 and other javascript engines are not.

Additionally, javascript is NOT more widely accessible - if anything, learning non-DOM-manipulated javascript is INCREDIBLY painful for a beginner.

Remember, these tools are for system administration and configuration management, not for writing applications.

Re: Puppet vs Chef, Fight

#30

Post by nigelk »

socratic wrote: post #5

Am I totally missing some obvious Chef documentation? The entirety of the documentation when I last looked seemed to be the wiki + the one 50-page O'Reilly book. I ended up literally printing out the wiki. (And the wiki seemed to be in a state of pretty extreme flux and/or disagreement with what blog posts suggested was best practice.) The business model of the companies promoting Puppet and Chef seems to be to charg…

"The business model of the companies promoting Puppet and Chef seems to be to charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?"

This is one of the reasons we're moving Puppet Labs from being a support company to a product company, and not for hosted services.

If your bread and butter comes in from support, you have no incentive to actually make your product easier to use. There are plenty of enterprise-y software companies who make lots of money operating like this, but that's not the sort of company I want to work for.

I'm quite proud of the rapid improvement we've made on the Puppet Docs over the last year since we hired NickF, our most excellent tech writer:

http://docs.puppetlabs.com/

I particularly like the solution focused docs he's done, as opposed to the dry reference material that presupposes a lot of knowledge.

http://docs.puppetlabs.com/learning/

Anyway, just wanted to point out that that's not our business model.

(Product Manager at Puppet Labs)

Post reply on HN