ssirowa14 commented on code in PR #925:
URL:
https://github.com/apache/spark-kubernetes-operator/pull/925#discussion_r4203207942
##########
spark-operator/src/main/java/org/apache/spark/k8s/operator/decorators/DriverResourceDecorator.java:
##########
@@ -73,6 +73,10 @@ public <T extends HasMetadata> T decorate(T resource) {
new ObjectMetaBuilder(resource.getMetadata())
.addToOwnerReferences(buildOwnerReferenceTo(driverPod))
.addToLabels(driverPod.getMetadata().getLabels())
Review Comment:
Thanks, this is a precise and accurate analysis. You're right that this PR
only addresses the key collision — a secondary resource that sets a conflicting
label now keeps its own value, but one that doesn't set the key still inherits
whatever the live driver pod carries, including pod-template-only and
webhook-injected labels (e.g. istio.io/use-waypoint: none leaking onto sibling
route/ingress Services).
I'd prefer to keep this PR scoped to the collision regression and treat the
root cause — propagating only the identity labels
(Utils.sparkAppResourceLabels) rather than the full driver-pod label set — as a
separate follow-up, since as you note it's another user-facing change
(secondary resources would stop inheriting arbitrary driver-pod labels
altogether) and would need its own migration note.
Shall I create a JIRA to track that follow-up?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
