[chef] Re: Re: Re: Re: Re: further whyrun testing

[Daniel DeLeo < >]

On Thursday, September 13, 2012 at 11:07 AM, wrote:

Hi Marc,

if you think this way, you are absolutely right.


But in a whyrun - run, chef already executes the built-in standard ohai plugins (and doesn't know if they are read-only or make changes to the system).


I can imagine of a solution which is downloading the custom ohai plugins from the server (or (chef-solo) from a directory) to a temp directory and execute the custom ohai plugins side-by-side (or after) with the built-in standard ohai plugins.

Maybe this is too complicated.


Thanks for reply Marc, at the moment I will use your solution.

If you need to just install the plugins without running other recipes, you might look into the `--override-runlist` option to run just the ohai recipe.

In a larger sense, you're hitting a specific case of a larger issue, which is that the accuracy of any no-op mode decreases as the difference between the desired state and current state increases. Chef's implementation accounts for this on a per-resource basis by detecting when a resource could not be converged (e.g, you're trying to put a file in a directory that doesn't exist, restart a service for which you haven't installed the code, etc.), issuing a message, and continuing as if the resource's prerequisites had been met. It's still up to you to apply your knowledge of the system to verify what why-run is telling you. This is unavoidable since many resources (execute, scripts, package installs via post-install scripts, service start/restart via init scripts, etc.) involve running code with side effects that cannot be determined by chef in advance. Modifying chef-client's internal state by running ohai plugins is similar in this regard.

That isn't to say that why-run is useless or "considered harmful", just that you need to keep in mind that chef-client cannot anticipate and account for the side-effects that normal recipe execution implicitly relies on.

-- 

Daniel DeLeo