*Use cases*
* User Dougie wants to change a setting on disk (for instance, in {{puppet.conf}} or in PE Hiera keys) that doesn't have an obvious measurable impact, but he still wants to confirm that the change is picked up by the daemon after it is restarted. (For instance, Dougie might want to confirm that changing a setting in {{puppet.conf}} takes effect if the setting also exists in Hiera or the classifier.) If the daemon dumps its settings on launch with debug-level logging enabled, Dougie could confirm that the daemon's new settings match the settings on disk.
* User Dougie launches the agent daemon, then user Bob changes the agent settings on disk. The agent daemon then runs uninterrupted for a length of time. Dougie is concerned that the setting on disk might have been changed, and if so wants to revert the change. However, he cannot remember the altered setting's original value. If the daemon dumped its settings on launch at info log level, Dougie could confirm that the settings on disk were changed and revert them to their original value.
* User Dougie launches the agent daemon, then user Bob changes the agent settings on disk. The agent daemon then runs uninterrupted for a length of time. The agent eventually exhibits signs of a potential issue related to an agent setting, and Dougie calls Support. Using the settings that Bob set on disk, Support cannot reproduce the problem. It also does not appear that the daemon reloaded the settings from disk. Dougie does not remember how the settings Bob changed were configured when the running daemon was launched. If the daemon dumped its settings on launch at info log level, Support could confirm the settings in use by the daemon and attempt to reproduce the issue. |
|
|
