On 2025/09/02 07:11:02 Štefan Miklošovič 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).
One of the very first JIRAs created for the Sidecar project is for the Bulk API
https://issues.apache.org/jira/browse/CASSSIDECAR-3. As you mention
above, some of the functionality falls within the Bulk API, while others don't
and we need to make sure the API allows you to define what can be done
in bulk and what can't.
> 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?
Yeah, I think there might be shortcomings with generating a CLI from the
spec in terms of the features we might get. I am not sure if it will work, but
it's worth evaluating what are the available options. I do think that if the
CLI generation is automatic the Sidecar client might not be in the picture,
and we'll be missing out on many features.
> 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 good point. And authentication / authorization will be different based on
the Cassandra cluster you are talking to. So the CLI will need to have some
way to configure authN/Z based on the cluster it is talking to.
> 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).
Yeah agreed. I don't think we need to have a different repository for the CLI.
>
>
> 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
> >> >
> >>
> >
> >
>
