fix(operator): keep selector labels authoritative#199
Conversation
👍 GitRank PR AnalysisScore: 20 points
Eligibility Checks
Impact SummaryThis PR fixes a label precedence bug in the Spritz operator's deployment reconciliation. The fix ensures that selector labels (which are authoritative for pod selection) remain immutable even when users provide conflicting labels in spec.Labels. The change reorders the label merge operations so selectorLabels take final precedence, preventing user-provided labels from breaking pod selection logic. Analysis DetailsComponent Classification: This PR affects the operator controller's deployment reconciliation logic, which doesn't fit neatly into a specific component category. It's categorized as OTHER since it's a general bug fix in the operator's label handling mechanism. Severity Justification: This is a P2 (Medium) severity bug. It fixes a functional issue where selector-owned labels could be overridden by user-provided labels, potentially breaking pod selection and causing deployment failures. However, it has a workaround (users can avoid conflicting label keys) and doesn't cause complete service outage. Eligibility Notes: Issue: True - PR title indicates this is a bug fix ('fix(operator)') addressing label authority issues. Fix Implementation: True - code changes align with the PR description; the merge order is reversed to keep selectorLabels authoritative. PR Linked: True - comprehensive description with TL;DR, summary, review focus, and test plan. Tests: True - adds regression test TestReconcileDeploymentKeepsSelectorLabelsAuthoritativeOnPodTemplate. Tests Required: True - this is a bug fix in business logic (label reconciliation) that affects pod selection behavior, requiring regression coverage. Analyzed by GitRank 🤖 |
TL;DR
This follow-up keeps selector-owned labels authoritative on the pod template while still propagating runtime policy labels and custom labels.
Summary
Review focus
Test plan