I respect your opinion about this but I just view it differently. There are about 40 methods in SidecarClient. Some of them are purely technical endpoints between Spark job + Sidecar and similar. CLI is for an operator of a cluster to use primarily. I do not think that every endpoint is going to be exposed in CLI. What do we actually want to expose? Everything? Why would anybody want to call "uploadSSTableRequest" or "restoreJobSummary" from CLI? Same e.g. for "createSnapshot". There is nodetool for that already (I believe that it is there for a Spark job primarily). I think it would make way more sense to have a CLI command for that if it was _cluster-wide snapshot_, coordinated by Sidecar, that would be way more justified to have a CLI command for. And so on ... What I am saying is that a lot of endpoints are there so that it is integrated with Analytics and there is no immediate need for that for an ordinary operator interacting with it on a day-to-day basis.
So for a handful of endpoints which actually make sense to expose, I would just do it manually for now. I do not vehemently oppose the idea of generation / automation, I am just saying that yes, you might actually spend more time on making it happen than just doing it by hand. We would probably also need to figure out how to _not generate_ a CLI command for some endpoint if there is no need / reason to expose it to a caller etc. I do not think that we should run to automation in every situation. I would add it if we clearly saw that it is problematic and time-consuming for people to work with it. If we worked with hundreds of endpoints and 5 clients in different languages, of course the primary goal would be to automate. But for now there was no discussion about that and these ideas are at best just theoretical. But yeah automate that if you guys want it. I am in no way going to prevent you from doing so :) On Tue, Sep 16, 2025 at 12:53 AM Joel Shepherd <sheph...@amazon.com> wrote: > On 9/3/2025 8:44 AM, Štefan Miklošovič wrote: > > > 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. > > A user might not be concerned about how the CLI is created, but as a > project there could be a lot of long-term benefit from vending a generated > CLI (and generated client) in terms of functional consistency, reduced > development time for new features, language coverage and so on. And all > that ultimately benefits the end users. > > If there's a pressing, critical need for a CLI today that might change the > equation, but I don't sense such a need. This sounds more like an > opportunity relatively early in the project's lifecycle to invest a little > more heavily now in automation and reap the benefit with each new feature > that sidecar rolls out. > > Thanks -- Joel. > > 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 >>>>> > >>>>> >>>> >>>> >>> >>>
