Live data from Hacker News

Puppet vs Chef, Fight

devopsanywhere.blogspot.com

31–40 of 109 posts

Re: Puppet vs Chef, Fight

#31
post #24
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.

I agree -- although I am sure you could write a system that manages config diffs, testing, backups and reporting in Fabric, it won't be pretty.

My current workflow for managing systems does use Fabric however. I maintain configuration using a custom framework and work under git/hg -- Fabric tarballs the tip, syncs the tarball to several dozen servers, and then runs and my configuration module on each server. I did use a bash script previously though.

Re: Puppet vs Chef, Fight

#32
post #23

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…

Unless chef and puppet are having a hard time finding developers, I don't see how javascript being more accessible is relevant.

Your point about them being over engineered is much more interesting than you just thinking we need yet another system but in a different language. And javascript is certainly not the only way to achieve the goals you list. Just seems like an attempt to start a language war honestly.

Re: Puppet vs Chef, Fight

#33
post #29
post #23

Earlier quoted context omitted.

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 applic…

While javascript engines are generally not shipped with OSes these days, it's moot because chef bundles its own ruby and ignores the ancient one in the OS. I suspect that's the case with python-based packages as well. I know HP Server Automation bundles its own python. It's easier to support a consistent python version across umpteen platforms than to debug your code in all the varying versions across so many distros and distro releases. Maybe Fabric can use the OS's python, but that's about the only example I know.

Re: Puppet vs Chef, Fight

#34

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…

If you are unhappy with Merb then convert it to pure rack or sinatra and send a pull request. It works and it's seriously as low of a priority as I can imagine. The server is nothing more than an API endpoint. You can (and people have) rewritten the entire server component in Python.

Re: Puppet vs Chef, Fight

#35
The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management.

Yes, there's a gap that the current crop of CM tools don't address (and why we see new versions of capistrano clones with a bit of system management sprinkled in) but the three major tools right now - Puppet, Chef and CFengine are all at a state where they address 95% of the use cases for system management and automation.

Re: Puppet vs Chef, Fight

#36
post #16

While I often see "Puppet vs Chef", I never see Bcfg2 mentioned. Is its low mindshare related to its quality, it's exclusion from the set of Ruby-based config management tools, its origin in the government space, or its terrible name?

It's probably the XML.

Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.

Re: Puppet vs Chef, Fight

#37
post #25

Earlier quoted context omitted.

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 )

I agree. What Chef lacks in documentation it makes up for it in community support. I have only been messing with Chef for a few weeks off and on but there is always someone to answer my questions in the IRC channel. Often it is someone from Opscode.

Re: Puppet vs Chef, Fight

#38
post #20

Earlier quoted context omitted.

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

The problem wasn't ruby 1.9, but ruby 1.9.1 specifically. I upgraded ruby to 1.9.2 and the stability issues went away. On 1.9.1 the server would randomly hang and require a kill -9+manual restart.

Re: Puppet vs Chef, Fight

#39
post #8

How does the free version of CFEngine http://cfengine.com/ compare to these two?

I'm curious about this as well. Does anyone have any experience with this? It would be interesting to hear someone's opinion since CFEngine seems to have been around for awhile.

Re: Puppet vs Chef, Fight

#40
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.

Check out cuisine https://github.com/sebastien/cuisine It is a good companion for fabric to handle user creation and package installs.

More info after slide 42 here: http://www.slideshare.net/ffunction/fabric-cuisine-and-watch...

Post reply on HN