Repository navigation
Kyverno background controller logs update conflicts while generating autoscaler objects #5705
Closed as not planned
Description
🤖 Generated by the Agentic Engineer
Problem and evidence
Kyverno's background controller logged 5 error-level lines in the 9 hours 17 minutes of logs retained at 23:05 UTC on 1 November, on the active Pod running the accepted patched image: failed to generate resources for gpol, caused by the object has been modified. All 5 came at second :46:10, the same minute the controller creates 53 update requests every hour. They hit autoscaler objects generated by two policies, auto-vpa-deployment (3) and auto-vpa-statefulset (2). The five objects named in those lines exist now.
Coroot can read error-level controller lines as a problem, so a routine update conflict may raise a false signal. This has not been shown in Coroot.
Unknown
- Whether the failed update request is retried and reaches the wanted state. The objects existing does not prove their content is current.
- Which writer the controller conflicts with. The vertical pod autoscaler updating its own status is a guess, not an observation.
- Whether the upstream image does the same. I did not measure it, so this is not known to come from the patch in Converge generated-resource cleanup when a downstream is already absent #5527.
Acceptance
- Show from a retained window whether each conflict is followed by a successful generation of the same object.
- If it converges, fix the cause at its owner without filtering logs or lowering severity, for example by retrying on conflict. No policy exception or blanket suppression.
- If it does not converge, treat stale generated objects as the defect and fix that.
- After delivery, read a fresh controller log window that spans at least 6 hourly passes, and Coroot.
Part of #2043.
Reacted by coderabbitai
Activity
coderabbitai commentedon Nov 1, 2026
🔗 Related PRs
#5414 - fix(vpa): keep generated autoscalers with their workloads [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
devantler commentedon Nov 3, 2026
Closing as a duplicate of #5691, which tracks the same fault and is the further-along record.
Both describe Kyverno's generating policies failing an update of an already generated object with a Kubernetes
Conflict("the object has been modified"), observed on 1 November on the same patched controller. #5691 has since reproduced that exact path from the released Kyverno source: the generator copies the stale resource version into its update and returns the conflict without re-reading. Theauto-vpa-deploymentandauto-vpa-statefulsetlines recorded here are instances of that path.The acceptance this issue added carries over to #5691: show that each conflict is followed by a successful generation of the same object, fix it at the owner with an ownership-preserving retry rather than log filtering, and afterwards read a controller log window spanning at least six hourly passes plus Coroot.
🤖 Generated with Claude Code