+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 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 <e.dimitr...@gmail.com> > 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. >> >> This seems non-controversial and the only reason it was not done before >> release (to the best of my knowledge) is the hope that updating through >> vrables will be done. Also, I agree with all points made around transition >> time on the ticket. >> >> I support the addition of those nodetool get/set commands. 4.1 and 5.0 will >> still be around for some time. >> >> Best regards, >> Ekaterina >> >> On Thu, 10 Jul 2025 at 7:23, Brandon Williams <dri...@gmail.com> wrote: >>> On Thu, Jul 10, 2025 at 6:20 AM Štefan Miklošovič >>> <smikloso...@apache.org> 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 >>> useful commands to nodetool. >>> >>> Kind Regards, >>> Brandon
