yew1eb commented on PR #3786: URL: https://github.com/apache/celeborn/pull/3786#issuecomment-5235636415
Thanks @SteNicholas — you're right that `celeborn-ratis.sh` exists and overlaps in intent. I weighed it before opening this PR but went with the REST/CLI path deliberately; I think they're complementary rather than redundant. The shell talks Ratis RPC (GPRC/NETTY), while these flags drive the master HTTP REST v1 endpoints (`/api/v1/ratis/*`) via the already-shipped `RatisApi` client — the same path `docs/celeborn_ratis_shell.md` itself calls "more convenient to operate the ratis service." `celeborn-cli master` already wraps seven OpenAPI clients from `celeborn-openapi-client`; `RatisApi` is the eighth in the same package and the only one not surfaced, so this just closes that gap with no new pendency or spec/server change. The REST path also sidesteps the shell's real operator friction: it's explicitly experimental with no compat guarantee, has the RPC-type trap where HA defaults to NETTY but the shell to GRPC (needs `-Draft.rpc.type=NETTY` or it silently fails), requires the full `-peers` list on every command instead of just the master HTTP endpoint, and runs outside the master HTTP auth layer. They even cover different things — REST has `GET /local/raft_meta_conf` (download the live raft-meta.co nf) the shell can't do, while the shell has `groupinfo/list` REST lacks — so this PR isn't proposing to remove it, just to surface the REST convenience the project already built and documented, consistent with how every other master op is exposed in `celeborn-cli`. @1fanwang — you authored these REST endpoints and know the cli module best. Should `RatisApi` be surfaced in `celeborn-cli`, or stay on the ratis shell ? -- 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]
