Whyrun and handlers?


#1

Ohai,

Recently we noticed that when running Chef in whyrun mode, the report
and exception handlers 1 seem to still fire, providing extra chatter
with the output of a non-run.

So my general question is:

Should handlers be enabled during a Chef run, or should each handler
be “smart” about handling whyrun mode?

-M


#2

They probably need to be smart. I’ve got two kinds of handlers: monitoring and logging. I’d like my graphite & airbrake handlers not to send stuff if things ‘break’, but I’d like the updated resources handler to keep displaying its output.

On 2013-03-13, at 08:26, Mike miketheman@gmail.com wrote:

Ohai,

Recently we noticed that when running Chef in whyrun mode, the report
and exception handlers 1 seem to still fire, providing extra chatter
with the output of a non-run.

So my general question is:

Should handlers be enabled during a Chef run, or should each handler
be “smart” about handling whyrun mode?

-M


#3

… but I’d like the updated resources handler to keep displaying its output.
Even if run in a whyrun mode, where the updated resources aren’t
actually updated?

On Wed, Mar 13, 2013 at 2:34 PM, Joseph Holsten
joseph@josephholsten.com wrote:

They probably need to be smart. I’ve got two kinds of handlers: monitoring and logging. I’d like my graphite & airbrake handlers not to send stuff if things ‘break’, but I’d like the updated resources handler to keep displaying its output.

On 2013-03-13, at 08:26, Mike miketheman@gmail.com wrote:

Ohai,

Recently we noticed that when running Chef in whyrun mode, the report
and exception handlers 1 seem to still fire, providing extra chatter
with the output of a non-run.

So my general question is:

Should handlers be enabled during a Chef run, or should each handler
be “smart” about handling whyrun mode?

-M