CASSANDRA-15254 only adds support for updating, we already have support for viewing (getter). The work to support mostly gets complicated for complex types such as collections, so I don’t feel its non-trivial as we have complex types in our config that has to be dealt with, so since there isn’t a patch for this I am in favor of 4.2 here (wouldn’t want to rush this patch).
I am in favor of #1, for configs that need to expose a setter they already exist, so do not need a new one. For configs that are not mutable they are exposed via the settings table, so don’t think we need to add into 4.1 but more than happy to have in 4.2 About your comment about supporting adding new JMX after https://issues.apache.org/jira/browse/CASSANDRA-15254 <https://issues.apache.org/jira/browse/CASSANDRA-15254> lands… I am 100% in favor of no longer adding unless the author really wants…. I wouldn’t want to block, but am cool making it optional/discouraged in favor of the settings table. About the v2 MBean… this makes things more complex to me, I rather have v2 methods like we have been doing... > On May 13, 2022, at 6:21 AM, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > 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 > <https://issues.apache.org/jira/browse/CASSANDRA-17562>. > Unfortunately, https://issues.apache.org/jira/browse/CASSANDRA-17562 > <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 > <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
