Feature #12513
Improve the way that "noop" reports are displayed/stored
| Status: | Accepted | Start date: | 02/08/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Keywords: | Affected URL: | |||
| Branch: | Affected Dashboard version: | |||
| Votes: | 1 |
Description
Reports that do nothing aren’t very interesting. Currently, we afford them more importance in the interface than they merit. Feedback from a customer is below, however, we need to make sure to avoid scenarios where the difference between unresponsive and static nodes disappears (see #5281).
Other than taking up space in the database and making it harder to find things (like actual changes that are important) - these do not provide any value to us. These runs can be condensed to display something like, change occurred at time A, from time A to time B no changes occurred, change occurred at time B, then no changes since…
Related issues
History
Updated by Daniel Pittman 3 months ago
- Status changed from Unreviewed to Accepted
Updated by Peter Meier 3 months ago
This should be definitely configurable. I imagine the totally valid use case for having noop reports:
One might want to constantly apply the catalog in noop mode and only apply it for real during certain maintenance windows. Having noop reports in the dashboard would give a preview of nearly all changes that will happen during the maintenance windows. It would be however fine, if noop reports would be marked somehow in the dashboard and the dashboard could be filtered to not show them.
Updated by Anton Gurov 3 months ago
- File 2-10-2012 1-57-20 PM.png added
Hi Peter,
Just to underline the distinction between “—noop” runs and “noop” runs that this feature request is looking to address.
I see “—noop” run as a simulated run to see what will change if things were to actually run. This is useful for troubleshooting and simulating runs.
Now, “noop” as in “no operations took place runs” that do not produce any operations because no operations were necessary (no resources to modify, no services to touch) are generally useless to report on or even worth storing(except maybe the last known run). See attached screenshot of the report page. Imagine trying to find something that actually changed on the node by going through pages and pages of redundant reports – this is unnecessary. We want to see the important stuff right away.
Looking at this from the operations point of view – I’d like to downplay the importance of the use case that you describe. The whole purpose of puppet is to maintain a certain state of a node and to address any deviations immediately. If you were to address your use case – you might be better off disabling puppet agent completely and only running it during the maintenance window.
Regards, Anton Gurov