ssirowa14 opened a new pull request, #925:
URL: https://github.com/apache/spark-kubernetes-operator/pull/925
### What changes were proposed in this pull request?
`DriverResourceDecorator` adds the driver pod's labels to every secondary
driver
resource (Services, ConfigMaps, ...) so they carry the pod's identifying
labels and
an owner reference for garbage collection. It did this with a single
`ObjectMetaBuilder(resource.getMetadata()).addToLabels(driverPod.getMetadata().getLabels())`,
which — because `addToLabels` is last-write-wins — overwrote any label the
resource
had already set under the same key with the driver pod's value.
This PR re-applies the resource's own labels **after** the driver-pod
labels, so that
on a key collision the resource's explicitly-set value wins:
```java
ObjectMeta metaData =
new ObjectMetaBuilder(resource.getMetadata())
.addToOwnerReferences(buildOwnerReferenceTo(driverPod))
.addToLabels(driverPod.getMetadata().getLabels())
// Re-apply the resource's own labels last so a label set explicitly
on
// the resource (e.g. a per-service label) wins over the driver-pod
label
// of the same key, rather than being overwritten by it.
.addToLabels(resource.getMetadata().getLabels())
.build();
```
Driver-pod labels whose key is **not** present on the resource are still
propagated,
so owner-reference / GC identity behavior is unchanged.
### Why are the changes needed?
Secondary resources whose metadata is caller-specified could not keep a
label that
collided with a driver-pod label. In particular, the Services built from
`driverServiceIngressList` / `driverHttpRouteList` / `driverGrpcRouteList`
take their
labels from the caller-provided `serviceMetadata`; any label there under a
key that
also exists on the driver pod was silently replaced with the driver pod's
value during
decoration. That made it impossible to give such a Service a label value
that differs
from the driver pod.
A concrete example: setting a service-mesh label (e.g. an Istio
`istio.io/use-waypoint` override) on a route Service's `serviceMetadata` was
clobbered
to the driver pod's value, so the Service ended up on the wrong side of the
mesh and
ingress to the driver endpoint broke. The decorator's purpose is to add the
owner
reference and propagate the pod's identifying labels for GC — not to
override metadata
explicitly set on the resource.
### Does this PR introduce _any_ user-facing change?
Yes. For a secondary driver resource that sets a label whose key also exists
on the
driver pod, the resource's own value is now preserved instead of being
overwritten by
the driver pod's value.
- Before: driver-pod label value won on a key collision (resource value
lost).
- After: the resource's explicitly-set label value wins; driver-pod-only
labels are
still copied onto the resource (unchanged).
Resources that do not set conflicting labels are unaffected.
### How was this patch tested?
Added `DriverResourceDecoratorTest` (spark-operator) covering:
1. a resource label wins over a driver-pod label of the same key (the
regression);
2. driver-pod-only labels are still propagated to the resource;
3. a resource with no labels of its own inherits the driver-pod labels (no
NPE);
4. the owner reference to the driver pod is added;
5. when the owner reference already exists, decoration is a no-op and
existing labels
are left untouched.
`./gradlew :spark-operator:test` passes. Also manually verified on a
Kubernetes
cluster that a Service created via `serviceMetadata` retained its own label
value
(differing from the driver pod) after reconciliation.
### Was this patch authored or co-authored using generative AI tooling?
Co-authored: Claude Code (Claude Opus 4.8)
--
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]
