I want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.
Refactor logging and outputting
- All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream.
- --verbose becomes an option for the outputter not the logger.
- "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format.
- Plans default to non-verbose, everything else defaults to verbose. -
no-verbose is accepted as an addition to -verbose
- "plan logging" becomes an outputter concept, rather than an executor concept
- without_default_logging becomes state tracked on the outputter that causes it to simply ignore action events.
- Human outputter without verbose prints starting action and summary for action messages.
- Human outputter prints full node-level result with --verbose
- For bolt apply without verbose, human outputter only prints a summary of the run
- For bolt apply with verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet".
- All output from this outputter can go to stdout (currently messages go to stderr for plans)
- When in non-plan mode behaves as it does currently.
- Logs entire JSON format of apply result on stderr for each node at --verbose
- This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticket
- The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors.
- Log files still default to "info".
- --debug still sets debug level for console logger, --verbose does not affect the logger at all
- A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the logger
Puppet log functions:
- Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.
- These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on without_default_logging