[chef] Re: stdout/stderr and exception/report framework

[Jay Feldblum < >]

Jesse,

The execute resource is really for executing a simple shell command. If you need a more complex set of shell commands or scripts in scripting languages, you should either

• use the script resource
• use the file or template resource to write a script file and the execute resource for executing that script file

You can write a handler that handles both success and failure, i.e., that is both an exception handler and a report handler. The handler will be triggered at the end of the run, whether the run succeeded or failed, and you can use it to find the resources you're interested in and check whether their states changed.

None of this requires modifying Chef's internals.

Cheers,

Jay

On Mon, Apr 9, 2012 at 1:11 PM, 2bjc 466 < "> > wrote:

Hi list,

We have two issues with chef at the moment. The first is that we want to write execute resources that leverage rsync and be able to behave in different ways based on the stderr/stdout of the rsync command. It looks like chef is specifically written to discard stderr/stdout with the exception of console output, which isn't useful outside of debugging (provider/execute.rb):

  if STDOUT.tty? && !Chef::Config[:daemon] && Chef::Log.info?
    opts[:live_stream] = STDOUT
  end

The second is that we would like to use chef's exception/report framework that is available after throwing an exception, but without throwing an exception. Is there a way to trigger an exception that does not cause chef to fail, or a way to use the exception/report framework without throwing an exception? There are many cases where we want to be notified of changes on a chef client, but do not want chef to terminate.

Currently we are working on redefining the Chef::RunStatus class to give us stderr/stdout, and writing a custom execute resource to pipe the stderr/stdout. If there are ways to do this without modifying chef internals, let us know, as we would prefer to run a vanilla chef install.

Thanks!

Jesse