[chef] Re: Whyrun verbosity

[Daniel DeLeo < >]

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
> (c) 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