[Pkg-puppet-devel] reports retention policy

[Jérôme Charaoui]

Le 2024-08-28 à 09 h 39, Antoine Beaupré a écrit :
> On 2024-08-28 09:26:07, Jérôme Charaoui wrote:
> 
> [...]
> 
>>> I also would like to ask: what do you do with so many puppet run
>>> reports? Do you read them during your week-ends, maybe? :)
>>
>> These reports could be useful for forensics and troubleshooting.
>>
>> We can argue all day long but it seems obvious that we're not going to
>> be able to agree about the appropriate retention policy, so this is my plan:
>>
>> - Remove the cron job from the package
>> - Ship a systemd service/timer pair to cleanup reports, disabled on
>> install
> 
> I don't see what this gives us: it's the worst of both worlds. Both zigo
> and I agree that we need *some* default retention, we just disagree on
> defaults.
> 
>> - Ship an example file to override the service to change retention time
>> - Properly announce the new service/timer pair in NEWS
>> - Document how to enable all this in README.Debian, and how to change
>> the retention time with a service unit override
> 
> At this point, I'm starting to lean towards zigo's position, to be
> honest: why *do* we need 30 days of reports? Aren't those better in
> PuppetDB?

Maybe, but clients need to be explicitly configured to send reports to 
PuppetDB (this isn't the default), see [0]

> I must admit I don't remember looking in those files at all, certainly
> not recently, and I don't know if the 30 days (essentially arbitrary)
> limit makes sense for "forensics and troubleshooting"...
> 
> Could you expand on what, exactly, you are using those reports for right
> now lavamind? :)

I don't use them for anything currently, and I manage this directory 
with a Puppet-managed cron job that deletes them after x days, as I 
suspect most users of this package are already doing.

Suddenly shipping a cron job that could conflict with existing retention 
policies really feels like a bad thing, especially when its not 
announced in NEWS.

If we really don't care about diverging from how upstream ships Puppet, 
and we agree reports aren't useful, then why not just disable them by 
default (report = false) ? [1]

Checking whether clients have applied their catalog can be done other 
ways than checking the report timestamp, such as looking at 
last_run_summary.yaml or PuppetDB (catalog_timestamp).

I mentioned before that the documentation is silent about managing the 
reports directory but actually it says this: "store: Stores the yaml 
report in the configured reportdir. By default, this is the report 
processor Puppet uses. These files collect quickly — one every half hour 
— so be sure to perform maintenance on them if you use this report." [2]

-- Jérôme

[0] 
https://www.puppet.com/docs/puppetdb/7/connect_puppet_server.html#enabling-report-storage
[1] https://www.puppet.com/docs/puppet/8/configuration#reports
[2] https://www.puppet.com/docs/puppet/8/report