[chef] Re: Re: --dry-run?

[mark bradley < >]

On Fri, Feb 17, 2012 at 11:29 AM, Bryan McLellan < "> > wrote:

On Fri, Feb 17, 2012 at 7:05 AM, mark bradley < "> > wrote:
> Is there any way to run the chef-client and have it only report what it
> thinks it's going to do rather than just doing it? This would save a lot of
> debugging time!

This has been in the Opscode backlog for some time, which is to say we
plan to implement it, but there isn't a set timeline.

There is, we believe, a good reason for it not being given a high
priority. In short, it is because we believe that noop is a great in
theory, but in practice it has to lie to you. There are previous
conversations on this subject which you can find linked to from this
ticket: http://tickets.opscode.com/browse/CHEF-13

Generally, the time when noop is useful is the time when your system
is simple enough that you can deduce everything quite easily. The time
when you cross over to noop lying to you is unfortunately quite subtle
and can be dauntingly early.

Example #1:

package "apache2"
service "apache2" do
 action [ :enable, :start ]
end
template "/etc/apache2/httpd.conf" do
 source "http.conf.erb"
 notifies :restart, "service[apache2]"
end

Now, assuming that the apache2 package is already installed but not
running, we would expect an output like this:

INFO: [noop] Would [ :enable, :start ] service[apache2]

But what if the apache2 package is not already installed?

INFO: [noop] Would :install package[apache2]
Chef::Exceptions::Exec: /usr/sbin/update-rc.d apache2 defaults
returned 1, expected 0

We can't check to see what action we would take against the service
because the service does not exist yet. Sure, we could skip the check
and  claim that it would start the service, but that is a lie if the
service is already running. This becomes incredibly important when you
consider notifications. If the template doesn't exist, or is
different, we would change it and say so, but what would happen with
the service? Are we still checking if it is running or pretending that
it is?

Example #2:

execute "/tmp/some-installer.sh" do
 not_if { File.exists?("/opt/some-software") }
 notifies :run, "execute[setup-software]", :immediately
end
execute "setup-software" do
 action :nothing
 command "/opt/some-software/setup.sh --unique-setting special_kittens"
end

Obviously we wouldn't run the first execute resource in any case,
because we don't know what it actually does. It may not be idempotent,
and usually is not. It may or may not actually change the system. But
what about the not_if and only_if conditionals? Should we evaluate
those or execute them (Ruby blocks get evaluated, strings are executed
as system commands)? In many cases these blocks don't change the
system, they just inspect them, but Chef can't guess your intentions.

Example #3:

execute "first-thing"

execute "second-thing" do
 only_if { File.exists?("/tmp/created-by-first-thing") }
end

# continue this pattern a couple times.

When your cookbooks get complex and each resource builds on a prior
resource, you will soon hit a circumstance where noop would say it
would run a resource, but then claim that all later resources would
not run. This would be a lie, because the first resource causes the
later resources to be triggered.

Bryan

Yes, I can see the paradox, but perhaps you're over thinking this? I'd rather have some  reporting and *know* that it might be lying than botch up my environment because of a mistake. At least I'll know that my scripts have a likelihood of being right.

Puppet seems to have solved this problem, somehow, and of course make -n from years gone by.

Not that I'm an expert on Chef, by any means. All I was getting at was that there is utility in this feature even though it may not be perfect. You guys are the experts, I leave it in your capable hands. Just think of this as a +1 vote for the feature. Maybe one day I'll know enough to contribute code too :)

Mark