There was a flurry of Puppet Versus Chef in last week or so. I don’t want to go into sorting all the details at this time, but I hope I add perspective and clarity to one of the subtopics.
People complain that Puppet is non-deterministic.
On a certain level that is like complaining that threads are non-deterministic. That’s the way the model works by design. If there is logic that depends on the order of execution, that code needs mutex/syncronization. Threads create issues, but they also solve some.
Puppet places a high priority on specificity. When order matters, the relationship must be specified explicitly.
Chef manages resources in the order they are specified. (Is that explicit ordering or implicit? I can’t decide.)
Here’s why I think the dividing line is a reflection of worldview…
Puppet aspires to bring a system from whatever state into compliance with the specified state.
Chef puts a higher priority on starting with a newly provisioned image in a known state and bringing up specific services.
Puppet guarantees that order matters on the level that it is specified. Chef guarantees that if you start with the same input, you get the same output.
Different emphasis on preconditions leading to different solutions.
The difference between Puppet and Chef is small compared to the difference between traditional IT management approaches (READ: meatcloud) and either one.
Use your powers for awesome…
fate = will && choice || circumstance 
January 20th, 2010 at 5:33 pm
That’s an excellent way of putting it.
I regard Chef’s ordering as ambiguously implicit. It’s not clear whether A follows B because it actually depends on B, or because it just happens to be the next thing on the page.
I think the split in worldview is partly related to that between developers and sysadmins. Chef satisfies developers because they can take a Slicehost and boot their app on it fairly easily. Puppet pleases sysadmins because we can manage large heterogeneous networks with many interdependent services.
January 20th, 2010 at 5:52 pm
This is why I have lot of respect for Puppet team. I remember talking to you in #puppet regarding some things out of which some are now implemented in Chef and other tools. I was approaching the configuration management with a specialisation based view. You guys (specially you) explained me that why things are so in Puppet and and why it’s more oriented on state rather than specific services and so on. That It’s not just about slapping up a few things and getting it running like I was imagining. That’s when I gained real faith in Puppet project. I got to understand why Chef is there and why Puppet is there. So I had the privilege of following the Puppet Vs Chef discussion with a more level head. Thanks Andrew.
January 21st, 2010 at 4:12 am
Here’s an interesting paper arguing for the importance of deterministic ordering in automated systems administration:
http://www.infrastructures.org/papers/turing/turing.html
January 21st, 2010 at 2:31 pm
That paper, I’d note, refers to Luke’s work on Isconf.
Saying that Puppet is non-deterministic is sort of like saying Make, Ant, or Maven are non-deterministic. It’s not true. You could, however, argue, that it assumes by default that elements are orthogonal — you have to explicitly state that there’s a sequence required.
The declarative approach shines when you consider predictable ongoing configuration changes as a more important case than the initial provision of servers.
January 21st, 2010 at 4:21 pm
Stu – it’s not at all like saying Make, Ant, and Maven are non-deterministic. The important bit here is at what level you get deterministic behavior – Puppet is not deterministic at the catalog level in all but one case (the case where each resource has a single dependency, all the way back to the first resource which has none.) When I say it’s non-deterministic, that’s what I’m talking about. A fuller explanation I posted to John’s blog:
http://bitfieldconsulting.com/puppet-vs-chef#comment-37
In terms of the world-view difference, I would argue that it’s actually a level higher than that. Chef cares that machines, and then the infrastructure as a whole, is correctly configured – a partially configured machine is a broken one. For me, things that got in my way of creating or debugging those issues were show stoppers, particularly at scale. It’s not that you’re less specific with Chef – it’s that with Chef you care more about what the system does in aggregate, rather than what the specific segments of the systems do in pieces.
Additionally, both tools are declarative – predictable ongoing configuration of changes is the goal from both systems, and any configuration management system with a modern world-view.
January 21st, 2010 at 4:42 pm
The other way I describe this is: “If you want order, Puppet makes you think about it.” And I think people, if they are serious sys-admins, SHOULD think about order and relationships and not assume the world will fall in the order they want.
January 21st, 2010 at 7:04 pm
@stu
Luke definitely spent time with ISConf, experience which influenced his thinking.
Make, Ant and Maven always do things in the same order last I checked.
The topological sort of the resource graph in Puppet is the source of the non-deterministic behavior because the sort is non-unique.
There are various ways to make the sort unique, but all of those potentially mask dependencies.
All the build tools that you mention tend to accumulate dependency cruft even on teams with discipline and good technical hygiene, often because there are hidden dependencies or dependencies that aren’t specified at the right level of granularity.
Chef and Puppet both attempt to be declarative, to the level that their modeling can account for what needs to exist on a system.
What is the difference between ongoing system configuration changes and application deployment? Mainly perspective, in my opinion…
Also as the cost of provisioning approaches zero, the line between provisioning, configuration and application deployment will blur.
It is already quite blurry.
@adam
Like I said, I didn’t want to break it all down here and now, but I have a much longer list of specific differences in worldview.
I think another difference that the discussion is starting to expose is the mindset of maintaining ongoing systems versus viewing each system as essentially disposable.
@james
I definitely agree people should think.
Dependency is a hard problem. Both Puppet and Chef have scenarios where dependency issues will cause the configurations to fail.
With Puppet, those scenarios work sometimes and fail other times, depending on the sort.
With Chef, changes may cause dependency failures but they are consistent failures given the same starting point.
I believe the dependency graph approach has benefits, but many of the advantages are latent and theoretical until there are better tools for analyzing and manipulating the graph.
January 25th, 2010 at 6:06 pm
Though it has to be said that “those scenarios work sometimes and fail other times” doesn’t make Puppet non-deterministic – which was the critique applied to it. I quoted Teyo’s response to Adam at:
http://www.kartar.net/2010/01/puppet-chef-deterministic-ordering-and-the-much-maligned-dsl/
January 25th, 2010 at 8:35 pm
http://en.wikipedia.org/wiki/Non-deterministic_algorithm
Puppet is non-deterministic by design.
Ordering is precisely why the same catalog can succeed or fail.
This is a feature of sorting the resource dependency graph.
January 22nd, 2010 at 3:21 pm
[…] it is ultimately a better process for building systems. We naturally have different ideas about how that process should execute, which among other differentiating factors is often that “goals are different but are left […]
February 2nd, 2010 at 9:29 pm
[…] Puppet, Chef, Dependencies and Worldviews There was a flurry of Puppet Versus Chef in last week or so. I don’t want to go into sorting all the details at this time, but I hope I add perspective and clarity to one of the subtopics. […]