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
language features.
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
generative constraints.
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
all".
I can go on, but it made me grumpy.
Adam
--> I'm writing paper about the software I'm developing, which uses chef as its
> CM tool.
> 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:
> http://www.usenix.org/events/lisa10/tech/full_papers/Delaet.pdf
> 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
> Daniel Cukier
Opscode, Inc.
Adam Jacob, Chief Product Officer
T: (206) 619-7151 E: ">
Archive powered by MHonArc 2.6.16.