Honestly, I think that paper is flat-out wrong about most of Chef.
From 3.1.1, " Chef on the other hand uses an imperative ruby DSL" - I
would argue that the DSL is a declarative one, with imperative
Section 3.1.3 states that you can “Define groups static groups or
groups based on queries”, which, while true, doesn’t cover the fact
that you can also use similar class based heirarchies to cfengine and
puppet (through include_recipe, etc.)
Section 3.1.4, under modeling of relations, gets it wrong using his
own framework. Chef can support all the different levels of
granularity he discusses, and the arity, but does not really do
Section 3.2.1, there are several Chef installs larger than 10k nodes.
Section 3.2.2 references export/collect resources as a workflow, but
using search and dynamic resource generation counts as “no workflow at
I can go on, but it made me grumpy.
On Wed, Aug 24, 2011 at 3:09 PM, Daniel Cukier firstname.lastname@example.org wrote:
I’m writing paper about the software I’m developing, which uses chef as its
I’m having some difficulties to demonstrate / prove in the paper why did I
choose chef and why it is better then other CM tools.
The only paper I found comparing CM tools was this:
And if you go through it, you will find that other tools are better
evaluated than chef.
I love chef and I wish I could demonstrate that it at least as good as the
best tools available.
Does anybody has any reference that could help me?
Or what are the arguments in the paper above that does not cover the best
parts of chef?
Thanks for any help
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: email@example.com