On 9/13/12 9:25 AM, "Brad Knowles" <b...@shub-internet.org> wrote:

It's awesome. It also has a significant impact on the operating
characteristics - the service itself is so much leaner and easier to
manage. It's delightful, and the team did a great job with it. What's
interesting about this shift from a broader point of view is this: once
the API on the server side was stable, it made sense to start to look at
what would make it truly sing in production.

So, that's not really true. Chef does not have a DAG for the resource
collection, but it's not because graphs are bad. It's because consistency
of ordering matters, and it is very difficult to get consistent ordering
out of a topologically sorted directed graph (which is how you get the
final order of resource to apply in Puppet.) They've done some work making
things more consistent, but there are still degenerate cases where it
isn't. Some people care, some people don't. It's cool. :)

In both cases we're building a collection of resources to manage. Puppet
builds a DAG with explicit dependencies and sorts it. Chef builds an array
and provides tools for manipulation.

Now, as it relates to why-run. The difficulty in implementing a dry-run
style mode in any tool aren't really around how you are modeling the
collection of resources under management. It's in deciding how to report
status to the user, and what assumptions are being made for you. For
example:

package "foo"

service "foo" do
  action [ :enable, :start ]
end

What can you say about the system when nothing has ever been done? You can
say that the "foo" package is or is not installed. You can say that the
service "foo" is or is not enabled or running. Taken in isolation, that
may be interesting. But what if we can't query the service at all? What if
the package "foo" doesn't actually install a service named "foo"?

Dan DeLeo was the one who came up with the solution to this sort of
problem, and it was this: we bake in to each resource the pre-conditions
that would need to be met in order for it work. So we say "package foo
would be installed", and "service foo would be enabled and started; but
the service doesn't exist, so we assume it comes from a package".  The
result is that we don't just tell you what we would do - we tell you the
assumptions by which we got there, which make the mode as reliable as we
can make it.

Nothing architecturally about Chef made dry run a challenge - it was
getting it to a place where we felt like it would be trustworthy that was
the hard part. Dan, and the rest of the team that built this feature,
knocked this problem out of the park.

If you want to know more about why dry-run modes are hard, and what
why-run does that is neat, check out this mailing list post from btm:

http://lists.opscode.com/sympa/arc/chef/2012-02/msg00257.html

And the why-run announcement:

http://www.opscode.com/blog/2012/09/07/chef-10-14-0-released/

Best,
Adam