alexandrefimov commented on PR #13:
URL:
https://github.com/apache/spark-connect-gateway/pull/13#issuecomment-5453118623
All code reading, not a run against a cluster.
**A session bound to a pod that leaves `Endpoints`.**
`resolve_session_detailed` returns the stored binding before it consults
members (`crates/routing/src/lib.rs:479`), and
`stickiness_holds_across_membership_changes` pins that: the session keeps
resolving to `a:1` after membership becomes `x:1, y:1, z:1`. With the static
pool that needs a config change; here membership changes when a pod dies, so
the binding outlives the backend. For Spark Connect that may be right — the
session state died with the pod, and re-routing would hand the client a
different session under the same id — so the question is whether it is
deliberate: forget a binding whose address is no longer a member, or let the
RPC fail?
**`Delete` empties the pool.** A Service deleted for good deserves that; a
recreate or an operator resync empties it while the pods are healthy.
`mark_unhealthy` refuses to evict optimistically so it does not race the
watcher — does the same argument make "keep the last membership and log" the
better default here?
**`warn!("k8s pool: watcher stream ended")` cannot fire.** `watcher()` is a
`stream::unfold` whose closure always returns `Some`, so the loop never exits;
errors arrive as `Err` items instead. For a permanent failure — RBAC revoked,
namespace deleted — that means an endless recover-and-warn loop with the pool
frozen at its last membership and `scg_backend_pool_size` still reporting it.
Worth surfacing as something other than a log line?
**Doc note.** "The watcher fully replaces the Vec on every event" holds
because the field selector pins one object. It stops holding for the
`EndpointSlice` source mentioned above: a Service's endpoints are spread over
several slices, so each `Apply` would clobber the others.
Could you file a SPARK sub-task under SPARK-58455 for user-aware placement,
or tell me which key to use? I have `OwnerLabelStrategy` written against
`scg-routing` and cannot create the issue myself.
--
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]
