<html>
<head></head>
<body>
<br>
<div dir="ltr">
On Aug 28, 2024 3:39 PM, Antoine Beaupré
</div>
<div dir="ltr">
> @zigo: what would 7 days look like on your end?
</div><br>
<div dir="ltr">
It looks like 4 times better than 30 days, though with 100 attached puppet agent, that still represent 40GB of reports for me: still too much, forcing me to tweak the default.
</div><br>
<div dir="ltr">
> I must admit I don't remember looking in those files at all, certainly
</div>
<div dir="ltr">
> not recently, and I don't know if the 30 days (essentially arbitrary)
</div>
<div dir="ltr">
> limit makes sense for "forensics and troubleshooting"...
</div><br>
<div dir="ltr">
That is my point: nobody looks at them...
</div><br>
<div dir="ltr">
The only thing we do is check if reports are old, meaning puppet didn't run!
</div><br>
<div dir="ltr">
cheers,
</div><br>
<div dir="ltr">
Thomas Goirand
</div><br><br>
<div class="bx-html">
<div class="bx-body">
<div class="quote">
On Aug 28, 2024 3:39 PM, Antoine Beaupré <anarcat@debian.org> wrote:<br type="attribution">
<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">On 2024-08-28 09:26:07, Jérôme Charaoui wrote: <br><br>
[...] <br><br>
>> I also would like to ask: what do you do with so many puppet run <br>
>> reports? Do you read them during your week-ends, maybe? :) <br>
> <br>
> These reports could be useful for forensics and troubleshooting. <br>
> <br>
> We can argue all day long but it seems obvious that we're not going to <br>
> be able to agree about the appropriate retention policy, so this is my plan: <br>
> <br>
> - Remove the cron job from the package <br>
> - Ship a systemd service/timer pair to cleanup reports, disabled on <br>
> install <br><br>
I don't see what this gives us: it's the worst of both worlds. Both zigo <br>
and I agree that we need *some* default retention, we just disagree on <br>
defaults. <br><br>
> - Ship an example file to override the service to change retention time <br>
> - Properly announce the new service/timer pair in NEWS <br>
> - Document how to enable all this in README.Debian, and how to change <br>
> the retention time with a service unit override <br><br>
At this point, I'm starting to lean towards zigo's position, to be <br>
honest: why *do* we need 30 days of reports? Aren't those better in <br>
PuppetDB? <br><br>
@zigo: what would 7 days look like on your end? <br><br>
I must admit I don't remember looking in those files at all, certainly <br>
not recently, and I don't know if the 30 days (essentially arbitrary) <br>
limit makes sense for "forensics and troubleshooting"... <br><br>
Could you expand on what, exactly, you are using those reports for right <br>
now lavamind? :) <br><br>
Right now, on our 100-server puppetmaster, we *have* no reports that I <br>
can find at all. So I kind of doubt we're using those at all! <br><br>
a. <br><br>
-- <br>
During times of universal deceit, telling the truth becomes a <br>
revolutionary act. - Georges Orwell <br></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>