Yes to a Sidecar CLI. As Yifan mentioned, I think we should leverage the OpenAPI specs yo autogenerate clients for different languages. I also see this being a separate subproject consuming this spec to generate release CLI artifacts, but I guess having separate subproject may come with some other different logistic challenges.
Bulk type operational calls using the CLI leveraging CEP-53 is, in my opinion, the natural next step for this. Bernardo > El sept 1, 2025, a las 3:26 p. m., Dinesh Joshi <[email protected]> escribió: > > +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] > <mailto:[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] <mailto:[email protected]>> >> Sent: Monday, September 1, 2025 10:25:52 AM >> To: [email protected] <mailto:[email protected]> >> <[email protected] <mailto:[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] <mailto:[email protected]>> >> Sent: Monday, September 1, 2025 7:42:36 AM >> To: [email protected] <mailto:[email protected]> >> <[email protected] <mailto:[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 >> >
