So, my essential point is that if that file did change – and it genuinely did – we should report that back, and provide better tools to filter it on the server side. The advantage of filtering on the client rather than the server is minimal, given we compress the data transmitted, so you are talking about a few bytes of network traffic, total.
Would you be equally satisfied if we allowed you to annotate that the resource was expected to change every time, and then alerted you only if it *didn't* change on a given run? (...or just never displayed that change to you?) Daniel On Tue, Oct 4, 2011 at 23:28, Matthew Black <mjbl...@gmail.com> wrote: > I could see a use case for it. When generating the facts.yaml for use with > mcollective, the reports are showing always at 1 change because of that even > if I set the log level to debug. That file will always change every run > because the information stored in facter is changes with each run. > > I can't think of another use case but I'm sure there might be others. > > On Oct 4, 2011, at 1:30 PM, Daniel Pittman wrote: > >> On Tue, Oct 4, 2011 at 10:16, Nigel Kersten <ni...@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. >> >> Daniel >> -- >> ⎋ Puppet Labs Developer – http://puppetlabs.com >> ♲ Made with 100 percent post-consumer electrons >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
