[chef] Re: --dry-run?

[Bryan McLellan < >]

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