> rubygems.org (http://rubygems.org) for testing. You can install this on a system using the
On Tuesday, July 3, 2012 at 1:19 PM, Bryan McLellan wrote:
> We've released a beta version of Chef 10.14.0 in gem format to
The output formatters also have an error inspector system for reporting relevant information in the case that chef-client fails. For example, when a recipe fails to compile, the error inspector will show you the relevant section of the recipe with a pointer to the line where the error occurred along with a filtered backtrace that excludes lines from internal chef code. We hope this will make your experience developing cookbooks much more pleasant.> "[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
In order to provide you with relevant output for failures, we needed to make some assumptions about what the likely causes of the error might be, so there might have been something we've overlooked. We would definitely appreciate any feedback on the error inspector system, especially if you find an error condition where the error inspector output is confusing or incomplete.
Thanks and enjoy,
--
Dan DeLeo
Archive powered by MHonArc 2.6.16.