Being able to remove the client code all together and generate from the spec would be awesome. (It is off the topic of this thread; I am aware of it :p). Way less code in Sidecar and Analytics; better decoupling.
- Yifan On Tue, Sep 2, 2025 at 1:02 PM Doug Rohrer <[email protected]> wrote: > I think, historically, we always wanted to be able to generate the client > but there were some technical challenges to doing so, which led us to the > hand-rolled client we have today. The less code we have to write by hand, > and the more client languages we can support, the better. > > That said, there's some specifics in the current client that we'd like to > maintain like the retry handling - perhaps the "generated" part is the bare > request/response methods + POJOs, and then there's a bit of a wrapper > around that with retry / instance selection logic, unless some > auto-generator can handle all of that. > > Doug > > On Sep 2, 2025, at 12:27 PM, Bernardo Botella < > [email protected]> wrote: > > Regarding client generation. I am not completely sure I am getting this > point. Is not there already SidecarClient class in Java, in the client > artifact, written manually, to call all the endpoints programmatically? So > if we had this artifact, what would be wrong with using that as a > dependency in cli? I just do not see why we would want to generate it > again. What is the purpose of SidecarClient then if not being used for > cases like this? > > > Yes, there is. What I am interested in here is to explore the possibility > of just ditching that “manually” maintained class in favor of auto > generated artifacts. That class is a Java client. If we can have official > clients for other languages coming out of the openAPI spec, I think we > should at least explore that. > > > There would also need to be some extra sauce around this as "sidecar-cli" > can be pointed to different clusters so there would need to be some > "context switching" done as well, I guess. > > Yeah, and that should also be part of the openAPI spec. Similar answer for > Francisco’s comment around authentication mechanisms. The current OpenAPI > spec is probably not complete as it doesn’t describe auth mechanisms, but > that is something that can be added as well: > Describing API Security > <https://learn.openapis.org/specification/security.html> > learn.openapis.org > <https://learn.openapis.org/specification/security.html> > <favicon.ico> <https://learn.openapis.org/specification/security.html> > <https://learn.openapis.org/specification/security.html> > > Regards, > Bernardo > > > On Sep 2, 2025, at 12:11 AM, Štefan Miklošovič <[email protected]> > wrote: > > Bulk API, yes. Definitely a good point. No reason to do the coordination > in the CLI. Operations like "set guardrails" are very good candidates for > that. Not so much for "restart" as that is another type of an operation > done a little bit differently (albeit inherently coordinated as well). > > Regarding client generation. I am not completely sure I am getting this > point. Is not there already SidecarClient class in Java, in the client > artifact, written manually, to call all the endpoints programmatically? So > if we had this artifact, what would be wrong with using that as a > dependency in cli? I just do not see why we would want to generate it > again. What is the purpose of SidecarClient then if not being used for > cases like this? > > There would also need to be some extra sauce around this as "sidecar-cli" > can be pointed to different clusters so there would need to be some > "context switching" done as well, I guess. > > How I see it is that cli would be the part of Sidecar repository, no > standalone project / repository. So it would share its release lifecycle / > versioning. Same way nodetool is part of a concrete Cassandra version (even > though one could technically use nodetool to connect to a cluster of a > different version and some operations would work, it is in general not a > good idea to mix nodetool from one Cassandra version against Cassandra node > of another version). > > > > On Tue, Sep 2, 2025 at 4:08 AM Bernardo Botella < > [email protected]> wrote: > >> 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]> 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 >>> > >>> >> >> > >
