Puppet users - Oct 2011 - RFC: Being able to exclude resources from reporting.

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.

Should we implement a metaparameter like this? Do the use cases justify
breaking the consistency of the model (report on everything) ?

Example:

exec { "apt-get update":
  report => false,
}

This would run every time, and you''d get interactive output about it,
but
the resource itself would not end up in the subsequent report.



-- 
Nigel Kersten
Product Manager, Puppet Labs

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <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.
> 
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

My tagmail.conf contains "all, !noreport: email@example.com," so if I
want to ignore a resource I just tag it with "noreport."  Of course,
that only applies to tagmail reporting.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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 <mjblack@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
<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.
>>
>> 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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

----- Original Message -----
> 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.
yes, the main concern isnt that it is or isnt in the report its that its
being reported on, mailed out, shown as red on dashboard etc

ditto for output on --test though that we can shut up generally with the 
loglevel meta parameter
> 
> 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?)
I think there''s a lot of files that changes frequently but not always
and it would be worth excluding those so more flexibility would be useful

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.