Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
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 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 > 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 wrote: > > 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 > useful commands to nodetool. > > Kind Regards, > Brandon > > >
Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
+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 > 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 wrote: >>> 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 >>> useful commands to nodetool. >>> >>> Kind Regards, >>> Brandon
Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
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 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 wrote: > >> 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 >> useful commands to nodetool. >> >> Kind Regards, >> Brandon >> >
Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
> 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 wrote: > 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 > useful commands to nodetool. > > Kind Regards, > Brandon >
Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
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 useful commands to nodetool. Kind Regards, Brandon
