Add proposal for selective pod metadata patching #196
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bmscomp
force-pushed
the
proposal/implement_selective_pod_metadata_patching
branch
2 times, most recently
from
f9fb7b4 to
1bbe02c
Compare
This proposal introduces support for in-place patching of Pod metadata (labels and annotations) without requiring rolling restarts. Key changes proposed: - Add PodDiff utility class to categorize changes as NONE, METADATA_ONLY, or REQUIRES_RESTART - Add patchPodMetadata() helper method to StrimziPodSetController - Modify maybeCreateOrPatchPod() to use PodDiff for detecting changes - Use Strategic Merge Patch for metadata-only changes This addresses the TODO at StrimziPodSetController.java line 466 and improves operational efficiency by avoiding unnecessary Pod restarts when only labels or annotations change. Signed-off-by: Said BOUDJELDA <[email protected]>
bmscomp
force-pushed
the
proposal/implement_selective_pod_metadata_patching
branch
from
1bbe02c to
54dc7aa
Compare
Author
|
@scholzj This is the proposal for selective metadata, a first version of the implementation is on strimzi/strimzi-kafka-operator#12386 |
scholzj
requested review from
Frawless,
PaulRMellor,
im-konge,
katheris,
ppatierno,
samuel-hawker,
scholzj,
see-quick,
sknot-rh and
tombentley
scholzj
reviewed
Feb 5, 2026
Member
scholzj
left a comment
scholzj
left a comment
There was a problem hiding this comment.
As this references the PR, I will share what I shared there as this needs to be addressed:
- Doesn't this remove annotations and labels added directly on the Pods by the user (or other components in the user's cluster)? I think we cannot afford it. So how do you figure out how to update the metadata? I think this is a very important aspect.
- The change to the Pod revision includes changes to the Metadata and you do not seem to have changed how the revision is generated. So I'm not sure I understand how you figure out whether the spec changed or whether only metadata changed.
- How do you prevent race conditions between the rolling update mechanism and the dynamic updates?
- In general, the Strimzi code would do the diffing differently through JSON/YAML. Should this mechanism from this PR be used, I think it should use the same logic as other parts of the code. However, we moved away from diffing Pods because it does not work well with all kinds of injected and default values. We started using the revisions instead. The main reason for it is the first point here.
- I think this implementation would not be compatible with #194 (that said, that proposal might suggest the way to do the dynamic metadata updates, assuming we figure out the first point here)
|
|
||
| 2. **Improved user experience**: Users often want to add custom labels or annotations for various operational purposes (e.g., cost tracking, monitoring integration). These changes should be seamless. | ||
|
|
||
| 3. **Better alignment with Kubernetes practices**: Kubernetes itself allows in-place patching of Pod metadata. Strimzi should leverage this capability. |
Member
There was a problem hiding this comment.
Actually, it does not. It allows you to add labels or annotations. But have you tried to edit deployment and see what happens? Rolling update.
|
|
||
| This means that adding a new annotation to a Pod (e.g., for monitoring or tracing purposes) will cause an unnecessary Pod restart and potential service disruption. | ||
|
|
||
| ## Motivation |
Member
There was a problem hiding this comment.
I don't think this is really a motivation or a use-case. That proper motivation or use-case would by why do you need to change the metadata so often that maintaining the in-place updates makes sense. That is a start. Without a convincing use-case, the proposal is not very interesting.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This proposal introduces support for in-place patching of Pod metadata (labels and annotations) without requiring rolling restarts. Key changes proposed: