fix(operator): propagate spec labels to pod templates#198
Conversation
⭐ GitRank PR AnalysisScore: 50 points
Eligibility Checks
Impact SummaryThe PR fixes a critical deployment bug where spec.labels (including Istio sidecar injection labels) were not propagated to pod templates, causing sidecars to fail injection. The fix adds label propagation to pod templates while maintaining selector boundary integrity for upgrade safety. A comprehensive regression test validates the fix and prevents future regressions. Analysis DetailsComponent Classification: This PR affects the operator controller logic for Kubernetes deployment reconciliation. Since no specific component multiplier exists for operator/controller changes, OTHER (1x) is the appropriate classification. Severity Justification: This is a P1 (High) severity bug fix. The issue prevented sidecar injection labels from reaching pod templates, breaking sidecar-based runtimes like tcdev entirely. This is a major functional impact affecting service deployment and observability infrastructure, though not a complete service outage. Eligibility Notes: This PR qualifies on all eligibility criteria: it fixes a reported functional bug in business logic (sidecar injection failure), the implementation correctly propagates labels as described, documentation is clear with test plan, and tests are included and required. The change modifies core reconciliation logic affecting pod scheduling and service mesh integration, making tests mandatory. Analyzed by GitRank 🤖 |
TL;DR
This fixes a deployment bug where runtime-policy labels were only applied to the Deployment object and not to the pod template. That broke sidecar-based runtimes like tcdev because Istio never saw the injection label.
Summary
spec.labelsontodeployment.spec.template.metadata.labelsReview focus
spec.labelsshould always propagate to workload podsTest plan
go test ./controllers/...tcdev-githubinstance getssidecar.istio.io/inject=trueon the pod templateReady