Thank you guys for the feedback. It was added already under 19952 and 20778
like a couple days ago. The soonest release this will be in will be 5.0.5
Regards
On Mon, Jul 28, 2025 at 4:53 PM Josh McKenzie wrote:
> +1 to adding. It's a user-facing API so we're going to be wedded to it for
> the l
+1 to adding. It's a user-facing API so we're going to be wedded to it for the
lifespan of the project; having existing MBean's we're wiring it to and a
relatively simple use-case makes this non-controversial to me.
On Sat, Jul 26, 2025, at 11:06 AM, Jordan West wrote:
> Similar to Ekaterina and
Similar to Ekaterina and Brandon, I agree with adding to nodetool.
We should ideally keep as much logic in the MBean and out of nodetool so
nodetool is a thin layer — which makes it low effort to maintain.
On Thu, Jul 10, 2025 at 06:39 Ekaterina Dimitrova
wrote:
> > Is it OK for the community i
> Is it OK for the community if we added nodetool get/set guardrailsconfig
commands to 4.1, 5.0 and trunk? Then, under (4), the CQL approach would be
delivered as well.
This seems non-controversial and the only reason it was not done before
release (to the best of my knowledge) is the hope that u
On Thu, Jul 10, 2025 at 6:20 AM Štefan Miklošovič
wrote:
> Is it OK for the community if we added nodetool get/set guardrailsconfig
> commands to 4.1, 5.0 and trunk? Then, under (4), the CQL approach would be
> delivered as well.
I am struggling to find a scenario where it wouldn't be ok to add
There is (1) which attempts to add guardrails get/set configuration to
nodetool.
When first encountered, I suggested that we might do a CQL vtable approach
instead.
This is still not done and Paulo asked if the nodetool approach could not
be still added to 5.0 (2)
The justification is that we ha
