Closed hardbyte closed 4 months ago
Hi @hardbyte - the intent of the API is to allow two styles:
In your case, you can periodically update the existing results with the new report result entries replacing the prior entries for the same resources.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Thank you for the clarification.
I've now switched to replacing results in existing PolicyReport resource instead of appending to them.
Netchecks is an operator which carries out periodic assertions and produces
PolicyReports
. Up until now I've been appending new results to a PolicyReport after each of these periodic tests.However this is leading to some confusion in the Kyverno Policy Reporter UI. With assertions both passing and failing (at different points in time). Could you shed any light into the assumptions or designs of PolicyReport CRD (and Kyverno Policy Reporter) with regard to handling historical results?
To be specific, say I have a network assertion
CheckDNSFiltering
which runs every 5 minutes. Would it be more in keeping with the design to create a new PolicyReport after each test (leaving the old PolicyReport), or updating the previous PolicyReport with the new results. I've come to the conclusion that appending to a single PolicyReport with the new results but still keeping the old is not in keeping with the design.Thanks!