Formal comparison between chef and other tools

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:

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

Daniel,

This section of the wiki is a great overview of why Chef is different (and
in my opinion better) than the others....

http://wiki.opscode.com/pages/viewpage.action?pageId=7274862#WhatisChef%3F-ChefCorePrinciples

John Willis

On Wed, Aug 24, 2011 at 4:09 PM, Daniel Cukier danicuki@gmail.com wrote:

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

--
John Willis
[ DTO Solutions, Inc. http://www.dtosolutions.com/* * | 1840 Gateway
Drive - Suite #200, San Mateo CA 94404
| o: *1.6**50.292.9660 x705 *| m: *
1.**919.244.9680 *| f: *1.**415.358.8435 *]

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

On Wed, Aug 24, 2011 at 3:09 PM, Daniel Cukier danicuki@gmail.com wrote:

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: adam@opscode.com

It's probably worth noting that the version of Chef documented was
0.8.x, no? Even the puppet version is fairly old.

One of the issues with studies like this is that it really doesn't
keep pace with the flow of open source development. Studies that have
this long of a cycle are pretty much pointless by the time they get
released when they include a rapidly changing opensource project.

Point being, using this paper is probably pretty silly just because
it's not even relevant with the current state of things.

On Thu, Aug 25, 2011 at 1:42 AM, Adam Jacob adam@opscode.com wrote:

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

On Wed, Aug 24, 2011 at 3:09 PM, Daniel Cukier danicuki@gmail.com wrote:

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: adam@opscode.com

Thanks John and Adam,

I appreciate your message and I agree with your points. Maybe the paper I
found is obsolete and kind of wrong in some aspects.

But I remain with my question: til now, I did not find a serious
and reliable paper or article doing a honest comparison between CM tools. I
wish this paper exists... if not, it would be a good topic to work on.

Today, I use chef mainly for three reasons:
1 - I like it
2 - It is the only tool I know well
3 - It works pretty well for my needs til now

These are perfectly acceptable reasons for personal or sometimes
professional uses, but MAYBE (because I really don't know) they are not
sufficient for a scientific usage.

On Thu, Aug 25, 2011 at 2:42 AM, Adam Jacob adam@opscode.com wrote:

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

On Wed, Aug 24, 2011 at 3:09 PM, Daniel Cukier danicuki@gmail.com wrote:

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: adam@opscode.com