shellfish007 opened a new pull request, #3767:
URL: https://github.com/apache/celeborn/pull/3767
### What changes were proposed in this pull request?
Adds a dedicated `ratis` SSL module so inter-master Ratis (Raft consensus)
gRPC TLS can use its own certificate/keystore, independent of the client-facing
`rpc_service` module — with a fully backward-compatible fallback.
- `TransportModuleConstants`: add `RATIS_MODULE = "ratis"`.
- `MasterClusterInfo.scala`: compute Ratis SSL from the `ratis` module with
fallback to `rpc_service`:
- `ratisSslEnabled = sslEnabled(ratis) || sslEnabled(rpc_service)`
- `ratisSslModule = ratis if sslEnabled(ratis) else rpc_service`
- `HARaftServer.configureSsl`: build the `SSLFactory` from the selected
module (same fallback).
Config keys (`celeborn.ssl.ratis.enabled/.keyStore/.trustStore/...`) come
from the existing `celeborn.ssl.<module>.*` machinery — no enumerated module
list needed.
### Why are the changes needed?
Master↔master Ratis TLS is currently derived from the `rpc_service` module
(`MasterClusterInfo.scala` → `HARaftServer.configureSsl`). But `rpc_service` is
also the client-facing control cert, so Ratis and external clients are forced
to share **one** presented cert. That cert must simultaneously satisfy:
- **clients**: signed by a CA they trust (e.g. a corporate CA) + the
gateway/SNI hostname, and
- **Ratis peers**: gRPC hostname verification against the internal master
pod FQDNs (`*.<svc>-master-svc.<ns>.svc.cluster.local`).
In a cross-cluster / TLS-passthrough-gateway deployment these requirements
conflict (the client cert has no internal SANs), so HA masters can't complete
the Ratis TLS handshake ("UNAVAILABLE: io exception" during leader election).
Decoupling lets operators give Ratis its own cert (internal SANs) while leaving
the client-facing cert untouched.
Note: CELEBORN-1356 already split the unified `rpc` module into
`rpc_app`/`rpc_service` for client-vs-server separation, but never separated
Ratis inter-master traffic from `rpc_service` specifically — this PR closes
that remaining gap.
### Does this PR introduce _any_ user-facing change?
Default behavior is unchanged: with only `rpc_service` SSL configured, Ratis
uses the `rpc_service` cert exactly as today. The new `ratis` module only takes
effect when `celeborn.ssl.ratis.enabled=true` is explicitly set.
### How was this patch tested?
Follows existing SSL-module patterns; no new APIs beyond the additive
`ratis` module constant and the fallback resolution helpers.
--
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]
