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?
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
>
