[chef] Chef 10.14.0.beta.1, whyrun and chef-client formatting

[Bryan McLellan < >]

We've released a beta version of Chef 10.14.0 in gem format to
rubygems.org for testing. You can install this on a system using the
"[sudo] gem install chef --pre" command.

This version includes a new feature that we've talked about for a long
time called "why-run." This feature allows you to run chef against a
system without the providers taking any action. A very important part
of the why-run feature is that it tells you why it makes the decision
that it did, so you can reason about the current and proposed state of
your system, hence the name.

The issue is that trying to model the state of a system where
resources (things you manage) are dependent on each other, without
running actions actions against these resources, doesn't scale. It is
easy to model a using package resource to install a package; if the
action is install, and the package is installed, then the result is
clear. Note that this doesn't ensure the package would be installed
successfully, but that we would attempt to do so. However, what about
modeling a service that depends on the package being installed
already, so the init script can be run? The service resource cannot
check the state of the service until the package is installed, so if
the package resource has not executed its action yet, we have to make
a choice. One option, used by existing tools [1], is isolate each
resource's state. We believe this limits the usefulness of a dry run
and doesn't fully convey to the user the likelihood that the actual
run will be different than what the dry run reports.

Given the use cases for a dry run, Opscode's engineering team came
back with a design that allowed for certain assumptions to be made in
each resource. If the service resource cannot find the appropriate
command to check the status of the service, Chef's why-run mode will
assume that the command would have been installed by a previous
resource and the service would not be running. This of course isn't
guaranteed to be the case, but we belief this will greatly increase
the usefulness of why-run over other possible designs.

Another area of concern is what to do with not_if and only_if
attributes. Chef assumes these are commands or blocks that are safe to
run in why-run mode. These conditionals are not designed to be used to
change the state of the system, but rather to help facilitate
idempotency for the resource itself. However, it is possible that you
may be using them in a way that modifies the system state, so be aware
of this.

The closer the current state of the system is to the desired state,
the more useful why-run mode is going to be to you. Running a full
run-list against a fresh system in why-run mode is not only unlikely
to be completely correct, it is going to produce significant output
which is probably less useful to you. Chef's why-run mode is not a
replacement for running your cookbooks in a test environment that
mirrors production as closely as possible. Opscode uses vagrant on
developer systems, an internal Openstack cloud and external cloud
providers to do so.

Creating a useful output for Chef's why-run also drove development of
an an output formatter. In the past there have been debates over
peoples preference for more or less informational logging at the
default level. Some users only want Chef to output a message if it
does something, others what to know what Chef is up to in the entire
run. You can now specify which output formatter to use for a
chef-client run. Along with the log-level, this gives you strong
capabilities to control what is displayed.

chef-client -Fminimal -lfatal # This will provide a short output with
a single character per resource, and then a summary
chef-client -Fdoc -lfatal # This format looks more like rspec and
gives you a friendlier human format and is what why-run uses.

We've been testing these new features internally and we're pretty
happy with them. Please take some time to try these out on different
platforms and let us know how useful they are. If you find any bugs
please file them in the usual place for Chef at
http://tickets.opscode.com.

-- 
Bryan McLellan | opscode | technical program manager, open source
(c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

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