Yes, nothing wrong with exploring the generation per se. However, I would not not spend too much time on that. The goal here is to have CLI to manage the cluster. Realistically by whatever means possible, generated or not. I would not like to see us spending the time on building "the ivory tower". A user does not mind how it is set up. Would it be nice to have? Sure.
On Tue, Sep 2, 2025 at 10:27 PM Yifan Cai <yc25c...@gmail.com> wrote: > 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 <droh...@apple.com> 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 < >> conta...@bernardobotella.com> 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č <smikloso...@apache.org> >> 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 < >> conta...@bernardobotella.com> 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 <djo...@apache.org> >>> 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 <yc25c...@gmail.com> 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 <yc25c...@gmail.com> >>>> *Sent:* Monday, September 1, 2025 10:25:52 AM >>>> *To:* dev@cassandra.apache.org <dev@cassandra.apache.org> >>>> *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 <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 >>>> > >>>> >>> >>> >> >>
