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
[DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk
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 have just GuardrailsMBean with management methods one can call but there is no user-facing tooling around this which would invoke them. An argument can be made that requiring an operator to manually invoke these methods is hardly user-friendly and it would be welcomed if we added get/set guardrails commands to nodetool directly. I was on a fence when I saw we are trying to add nodetool commands to 5.0 / 4.1 while the "end goal" is to have it on CQL but the feedback given from Brandon (3) / Maxwell is that they would still welcome nodetool approach and CQL might be reserved for 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. While adding something quite late to 4.1 / 5.0 when it comes to (technically) an improvement is rather special and should be done exceptionally, we think it still makes sense, especially when it makes the lives of operators simpler in this regard. I do not think that additions like this should not happen when they are contributing to overall betterment of user experience for the whole feature (guardrails) and they are clear additions not touching internal server code as such. The only way a user can toggle guardrails in runtime is via manual invocation of MBean methods and there is no real reason we should not enrich Cassandra with tooling calling it for the reasons explained earlier. Regards (1) https://issues.apache.org/jira/browse/CASSANDRA-19552 (2) https://issues.apache.org/jira/browse/CASSANDRA-19552?focusedCommentId=18003580&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18003580 (3) https://issues.apache.org/jira/browse/CASSANDRA-19552?focusedCommentId=18004163&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-18004163 (4) https://issues.apache.org/jira/browse/CASSANDRA-19553
