kubernetes: SSA triggers update events on apply to resource when it is no-op
What happened:
Using SSA patch to create and manage a couple of resources (specifically those, the list may change in the future) resulted in endless hot loop, as each apply increases resourceVersion of the resource even if this is a no-op.
What you expected to happen:
Apply resources once to establish ownership on the fields and forget. Operator should not be triggered by constant resourceVersion changes if does not change any object spec or metadata by a new patch.
How to reproduce it (as minimally and precisely as possible):
Take a sample Deployment or other resource and forcefully apply it multiple times using controller-runtime client.

Anything else we need to know?:
This issue appeared using controller-runtime client implementation, but could be present in other clients. kubectl is not affected.
Environment:
- Kubernetes version (use
kubectl version): v1.20.0+aa519d9 and before - Cloud provider or hardware configuration: aws/openstck, does not matter
- OS (e.g:
cat /etc/os-release): ~ - Kernel (e.g.
uname -a): ~ - Install tools: ~
- Network plugin and version (if this is a network-related bug): ~
- Others: ~
/sig api-machinery /wg api-expression
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 29 (25 by maintainers)
Commits related to this issue
- Mitigate hot-loop in SSA Compare objects on update, while stripping fields which change on no-op resource update. Avoiding https://github.com/kubernetes/kubernetes/issues/100024 — committed to Danil-Grigorev/cluster-cloud-controller-manager-operator by Danil-Grigorev 3 years ago
- Mitigate hot-loop in SSA Compare objects on update, while stripping fields which change on no-op resource update. Avoiding https://github.com/kubernetes/kubernetes/issues/100024 — committed to Danil-Grigorev/cluster-cloud-controller-manager-operator by Danil-Grigorev 3 years ago
- Mitigate hot-loop in SSA Compare objects on update, while stripping fields which change on no-op resource update. Avoiding https://github.com/kubernetes/kubernetes/issues/100024 — committed to Danil-Grigorev/cluster-cloud-controller-manager-operator by Danil-Grigorev 3 years ago
Can you show me the exact object after it’s been applied (as returned by the apiserver in the apply request) and the object that you intended to apply (as seen in the file, before it’s been decoded). That would greatly help me understand what’s going on, thanks!