I agree a CLI could unlock new use cases and help ops, but I’m a bit concerned about adding another interface for Sidecar to maintain on top of REST and the Client SDK. It cloud also create another potential attack surface and versioning challenge.
Since Sidecar already vends an OpenAPI spec, maybe the CLI could be generated from that instead. The generator could live outside the repo (e.g. something like restish<https://github.com/rest-sh/restish>, though I haven’t used it myself). - Yifan ________________________________ From: Francisco Guerrero <fran...@apache.org> Sent: Monday, September 1, 2025 7:42:36 AM To: dev@cassandra.apache.org <dev@cassandra.apache.org> Subject: Re: [DISCUSS] CLI for Sidecar and Guardrails By Sidecar Hi Stefan, I think the CLI is the natural evolution for the Sidecar Java client and it will help simplify the management of Cassandra. Thanks for bringing this up to the mailing list. Best, - Francisco On 2025/09/01 10:09:55 Štefan Miklošovič wrote: > Hi, > > I just ask two questions / discuss two topics at once to save time for > everybody. > > 1) CLI > > Seeing CEP-53 (and not only that), I am just asking myself, how are > operators actually going to use this on a daily basis when there are "just > endpoints" exposed? Somebody has to call them, right? What kind of tooling > do you plan to have for this? Are you going to literally call endpoints, > crafting the bodies etc? Hardly. > > So my idea is ... why not to have a Sidecar CLI? A command line tool which, > when invoked, would call these endpoints for you? For example when CEP-53 > is in place which is going to restart the cluster, I would love to use > something like > > $ sidecar-cli restart > > and be done with it? > > Then it would also display the progress and so on. > > I can imagine this would be used for other endpoints going to happen / > which are already there. We would have basically "nodetool for sidecar". > > 2) > > Guardrails are configured by YAML / JMX / nodetool (by > get/setguardrailsconfig added recently). However, this is still done _per > node_. > > Building on top of 1), could not we have > > $ sidecar-cli setguardrail xyx false > > which would basically call it for every node in the cluster? Sidecar can > just call whatever it wants. No point doing it per node by nodetool if one > deploys Sidecar. > > We could also have an endpoint which would display any discrepancies when > it comes to guardrails. E.g. we would know that a guardrail is configured > the same way, cluster-wide. Right now, you need to go node by node and > check it yourself: > > $ sidecar-cli guardrails --diff > > Would show which guardrails are not the same everywhere with nodes it > differs so you can fix this if you want. > > Regards >
