Hi everyone, Code freeze started but I wanted to seek for community agreement on one important topic.
After CASSANDRA-15234 we have the new yaml format for duration, data storage and data rate config parameters. New JMX methods with the new format are created since then for new parameters like guardrails for example. The old JMX methods for our config are still there so people can keep on using them to set the parameters by only value with the old default units. I opened a ticket for adding also JMX methods for the new value format but it was not implemented so far in favor of https://issues.apache.org/jira/browse/CASSANDRA-17562. Unfortunately, https://issues.apache.org/jira/browse/CASSANDRA-17562 did not land before the code freeze. So my question is about the path forward and these are the options I see: 1. Neither https://issues.apache.org/jira/browse/CASSANDRA-17562 or CASSANDRA-15254 lands in this release. People still have the old JMX methods 2. CASSANDRA-15254 lands as being just getters and setters, non-invasive and quick but we will have to keep on supporting them or deprecate after CASSANDRA-17562 lands in next release. The tricky part is that some of the old JMX methods already have name without unit like getCasContentionTimeout and we can't just change them and break compatibility 3. CASSANDRA-17562 gets implemented 2. brings another important question. The moment CASSANDRA-17562 lands, do we still want to add JMX? Shall we continue adding new getters/setters? If the answer is "yes, we shall continue" and option 1, then I suggest we deprecate methods like getCasContentionTimeout in this release in favor of new ones with unit suffix so we can change those names to be used for the new format with the next release. Otherwise, there was a suggestion we add v2 StorageProxyMbean as this is where we see now problem. (Thanks Andres for raising the point!) Best regards, Ekaterina
