Whyrun verbosity


#1

Here’s an whyrun output where we’re only going to change the utime on
a file, but there’s still a screen full of output.

You’ll notice two outputs, “verbose_logging_true” is what happens by
default. “verbose_logging_false” is what happens if you put
’verbose_logging false’ in your client.rb (it disables the processing
messages).

Thankfully at the end of the run it tells us that 1 resource was
updated so we know to look back and visually scan for what changed to
ensure it was what we were expecting. This run is only with a couple
cookbooks, and I’ve seen much more output when running a node with the
wordpress cookbook which has lots of dependencies like apache and
mysql.

Also, there’s a missing space between the action and the timestamp.

What do you think? I usually prefer verbose_logging off myself, but
definitely in this situation. Since verbose_logging defaults to true,
I’m not sure if we could optionally default it to false or not for
why-run.

We’re starting a bit of a table to encourage folks to work together to
get some test coverage for Whyrun. Head over here to the wiki for more
information: http://wiki.opscode.com/display/chef/Whyrun+Testing


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


#2

On Monday, July 30, 2012 at 1:38 PM, Bryan McLellan wrote:

Here’s an whyrun output where we’re only going to change the utime on
a file, but there’s still a screen full of output.

You’ll notice two outputs, “verbose_logging_true” is what happens by
default. “verbose_logging_false” is what happens if you put
’verbose_logging false’ in your client.rb (it disables the processing
messages).

https://gist.github.com/55e296aa501ddad51d2a

Thankfully at the end of the run it tells us that 1 resource was
updated so we know to look back and visually scan for what changed to
ensure it was what we were expecting. This run is only with a couple
cookbooks, and I’ve seen much more output when running a node with the
wordpress cookbook which has lots of dependencies like apache and
mysql.

Also, there’s a missing space between the action and the timestamp.

What do you think? I usually prefer verbose_logging off myself, but
definitely in this situation. Since verbose_logging defaults to true,
I’m not sure if we could optionally default it to false or not for
why-run.

We’re starting a bit of a table to encourage folks to work together to
get some test coverage for Whyrun. Head over here to the wiki for more
information: http://wiki.opscode.com/display/chef/Whyrun+Testing


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

In the long-term, we’d like the output formatters to replace the logger as the primary output when using Chef on the command line (when a human is watching the output as it happens). In our internal testing of whyrun, we’ve generally been using -l fatal to keep the logging output quiet, but it’s tricky to have whyrun set the log level without overriding what the user has set via command line or config file.

We could have make output formatters the default/primary output for Chef in 10.14, but were concerned that there could be cases where Chef would appear to “mysteriously fail” because important messages were only written to the logs and not to the formatted output–in other words, we want to let the output formatters “bake” as an opt-in feature so we can get real-world experience about error cases we might have overlooked. Currently, the error inspector output is turned on by default, but you have to use something like -F doc to turn on the formatter output for a normal chef-client run.

In addition to the above, there are still some unanswered questions about handling log versus formatted output once the formatters do become the default. If anyone’s tried the formatted output and has opinions on this, I’d be happy to hear it.


Dan DeLeo