L. C. Hsieh created SPARK-59445:
-----------------------------------
Summary: Run the multi-replica Redis affinity end-to-end
walkthrough in CI
Key: SPARK-59445
URL: https://issues.apache.org/jira/browse/SPARK-59445
Project: Spark
Issue Type: Sub-task
Components: Connect
Affects Versions: connect-gateway-0.1.0
Reporter: L. C. Hsieh
Assignee: L. C. Hsieh
The e2e workflow now covers baseline routing, JWT identity, the backend
trust boundary, and per-tenant pool isolation, but nothing in CI stands
the gateway up as more than one replica. The multi-replica walkthrough
under deploy/examples/e2e-multi-replica-redis has never run
automatically, so the chart's Redis topology and the gateway's behaviour
when a replica dies are only verified by hand.
The cross-replica semantics themselves are already covered in-process by
the ha_smoke example, which runs in the integration job against a real
Redis. What is missing is the Kubernetes shape around it: the bundled
Redis StatefulSet, the synthesized redis:// URL, two gateway replicas
behind one Service, and a pod actually being deleted.
This adds an e2e-multi-replica-redis job that asserts:
(1) Both gateway replicas report affinity_store=redis on startup. The
pod count is checked first, so a selector that matched nothing could not
let the check pass silently.
(2) A session driven through the Service writes its binding to Redis,
under the documented key shape, with a value that is one of the real
backend pod IPs and a TTL within the configured hour. Redis is asserted
empty beforehand so a stale key cannot satisfy this.
(3) After deleting one replica, the binding is unchanged, and a client
arriving at the replacement pod -- port-forwarded directly, so the
surviving replica cannot serve it -- reaches the same backend. The
replacement's own log must name that backend, an address it could only
have read from Redis.
(4) Fresh sessions still spread across both backends. Without this,
assertion 3 would also pass on a gateway that always picked the same
backend regardless of affinity.
Verified locally against a kind cluster first. The replacement replica
returned the same serverSideSessionId as the original, confirming the
same Spark driver answered, and eight fresh sessions split 4/3 across the
two backends while the pinned session stayed put.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
