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

**URL:** <https://discourse.chef.io/t/chef-10-14-0-beta-1-whyrun-and-chef-client-formatting/2954>\
**Category:** Chef Infra (archive)\
**Created:** [July 3, 2012, 8:19pm UTC](https://discourse.chef.io/t/chef-10-14-0-beta-1-whyrun-and-chef-client-formatting/2954 "2012-07-03T20:19:31Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bryan\_McLellan1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bryan_mclellan1/32/426_2.png) [@Bryan\_McLellan1](https://discourse.chef.io/u/Bryan_McLellan1)\
**Post date:** [July 3, 2012, 8:19pm UTC](https://discourse.chef.io/t/chef-10-14-0-beta-1-whyrun-and-chef-client-formatting/2954/1 "2012-07-03T20:19:31Z")

</div>

We’ve released a beta version of Chef 10.14.0 in gem format to  
[rubygems.org](http://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](http://tickets.opscode.com).

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

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

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [July 5, 2012, 3:58pm UTC](https://discourse.chef.io/t/chef-10-14-0-beta-1-whyrun-and-chef-client-formatting/2954/2 "2012-07-05T15:58:29Z")

</div>

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  
> [rubygems.org](http://rubygems.org) ([http://rubygems.org](http://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](http://tickets.opscode.com).
> 
> --  
> Bryan McLellan | opscode | technical program manager, open source  
> (c) 206.607.7108 | (t) @btmspox | (b) [http://blog.loftninjas.org](http://blog.loftninjas.org)
> 
> [1] [chef - [chef] Re: Re: Re: --dry-run?](http://lists.opscode.com/sympa/arc/chef/2012-02/msg00257.html)  
> 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.

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

---

<div class="post-metadata">

**Author:** ![Jeremiah\_Snapp](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jeremiah\_Snapp](https://discourse.chef.io/u/Jeremiah_Snapp)\
**Post date:** [July 5, 2012, 4:40pm UTC](https://discourse.chef.io/t/chef-10-14-0-beta-1-whyrun-and-chef-client-formatting/2954/3 "2012-07-05T16:40:56Z")

</div>

It sounds like why-run and the output formatters have been really well  
designed. Thanks for everyone's work to add such powerful features!

Jeremiah

On Thu, Jul 5, 2012 at 11:58 AM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> 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  
> > [rubygems.org](http://rubygems.org) ([http://rubygems.org](http://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](http://tickets.opscode.com).
> > 
> > --  
> > Bryan McLellan | opscode | technical program manager, open source  
> > (c) 206.607.7108 | (t) @btmspox | (b) [http://blog.loftninjas.org](http://blog.loftninjas.org)
> > 
> > [1] [chef - [chef] Re: Re: Re: --dry-run?](http://lists.opscode.com/sympa/arc/chef/2012-02/msg00257.html)  
> > 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.
> 
> 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