If not obvious, CLI would just reuse Sidecar Client in Java. Nobody is going to implement "curl in Java" here.
On Mon, Sep 1, 2025 at 12:09 PM Štefan Miklošovič <smikloso...@apache.org> 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 >
