+1 on the sidecar-cli and cluster-wide operations. Like Yifan said, cluster-wide operations should be delegated to the C* Sidecar. The recent CEP-53 for rolling restarts is an example of a cluster-wide operation and was one of the original goal of CIP/CEP-1.
On Mon, Sep 1, 2025 at 11:33 AM Yifan Cai <[email protected]> wrote: > I see the “guardrail by sidecar” as a feature can be leveraged by > Sidecar’s (cluster-wide) bulk-api capability. It is not implemented, but > planned. Rather than handling cluster-wide operations in the CLI, bulk api > seems like a better fit. The client (CLI) just needs to call the API. In > other words, the Sidecar server acts as the coordinator, not the client. > > - Yifan > > ------------------------------ > *From:* Yifan Cai <[email protected]> > *Sent:* Monday, September 1, 2025 10:25:52 AM > *To:* [email protected] <[email protected]> > *Subject:* Re: [DISCUSS] CLI for Sidecar and Guardrails By Sidecar > > 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 <[email protected]> > *Sent:* Monday, September 1, 2025 7:42:36 AM > *To:* [email protected] <[email protected]> > *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 > > >
