Feature #7555
should be able to exclude a resource from reporting
| Status: | Needs More Information | Start date: | 05/17/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Nigel Kersten | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | mcollective | |||
Description
There are many cases where you would want a resource to run always – like an exec that does an apt-get update for example – these will constantly spam the reports with changes and it would be good if there was a meta parameter that lets people choose to not have a resource be reported on.
I realize its a bit controversial but it would make some peoples lives a lot better, by default everything should be reported though as it is today
History
#1
Updated by James Turnbull about 2 years ago
- Status changed from Unreviewed to Needs Decision
- Assignee set to Nigel Kersten
#2
Updated by Nigel Kersten over 1 year ago
- Status changed from Needs Decision to Needs More Information
RI or anyone else, can you think of an example other than “commands which always run” ?
I do get the use case, but find myself undecided whether it’s worth breaking such a core assumption. Another use case may help tip the balance.
#3
Updated by R.I. Pienaar over 1 year ago
Nigel Kersten wrote:
RI or anyone else, can you think of an example other than “commands which always run” ?
files that always update like mcollective facts.
People are doing:
exec{"/bin/true":
unless => "/path/to/script"
}
where the script always return 0, thats really nasty nasty nasty but they’re forced to do that cos they are not given this choice.
#4
Updated by Nigel Kersten over 1 year ago
or worse:
exec { "somescript":
returns => [0,1,100],
}
:)
#5
Updated by Nigel Kersten over 1 year ago
I’ve taken this to the user list for discussion.
#6
Updated by Daniel Pittman over 1 year ago
On Tue, Oct 4, 2011 at 10:16, Nigel Kersten nigel@puppetlabs.com wrote:
As per: https://projects.puppetlabs.com/issues/7555 it looks like we’ve got some use cases around excluding some resources from being reported on to reduce noise.
This feels like solving the problem on the wrong side to me.
Should we implement a metaparameter like this? Do the use cases justify breaking the consistency of the model (report on everything) ?
This is worse than that: it bakes in the assumption that the reports are not a graph, or that we can just discard structural elements in that graph, by allowing us to ditch what would otherwise be a vertex.
One of the proposed enhancements to the report – which I think is hugely valuable – is that we return the augmented graph from the client side, where things like file recursion, or autorequires, can change the catalog we sent down. Excluding something from that may be a huge structural change, and it is certainly going to make correlation between that graph and the original catalog extremely difficult to discover.
So, no, I do not believe we should support this. Better, I think, to support that feature in our reporting tools, or make it easier for people to build that in their tools.
#7
Updated by R.I. Pienaar over 1 year ago
Daniel Pittman wrote:
So, no, I do not believe we should support this. Better, I think, to support that feature in our reporting tools, or make it easier for people to build that in their tools.
well, I didnt really dictate an implementation only the outcome.
you can flag events as silent/ignorable and the report tool can choose to ignore it. that would also solve the problem from the point of an end user.