viirya commented on PR #30:
URL:
https://github.com/apache/spark-connect-gateway/pull/30#issuecomment-5734388850
Closing for now — deferring rather than rejecting. Grouping worked exactly as
intended here (this is the first PR raised under the `kube` group added in
SPARK-59550, and `kube` + `k8s-openapi` correctly move together), but a
`kube`
3.1 -> 4.2 major jump wants a focused PR rather than a place in a dependency
batch.
What it touches is the backend discovery path. `crates/pool-k8s` sits
directly on
the surface that changes across these majors:
```rust
use k8s_openapi::api::core::v1::Endpoints;
use kube::api::Api;
use kube::runtime::watcher;
```
`watcher` appears 25 times in that crate and `Endpoints` 20, so this is not
an
incidental dependency — it is how the gateway learns which Spark Connect
backends
exist. `k8s-openapi` 0.27 -> 0.28 also matters on its own: it is configured
with
`features = ["latest"]`, so the bump moves the Kubernetes API version the
generated
types target.
Two reasons that argues for its own PR:
1. **A green build would not be sufficient evidence.** The watcher's
behaviour under
re-list, error and reconnect is what the gateway depends on, and that is
exercised by the kind-based e2e jobs rather than by compilation. Any
upgrade here
should be judged on those, with the `pool-k8s` code reviewed against the
4.x
watcher semantics, not merged because it compiles.
2. **`k8s-openapi`'s `latest` feature deserves a deliberate choice**, since
it
decides which Kubernetes versions the gateway is built against.
Nothing here suggests the upgrade is wrong — only that it should be reviewed
as a
Kubernetes-client change, which is what it is. Reopening or re-raising it as
a
dedicated PR is the right next step when someone can give it that attention.
Thanks, dependabot.
--
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]
