s/I don’t feel its non-trivial/I feel its non-trivial/. Update support requires a good amount of testing, so isn’t as simple as calling the existing setters (mostly defining a Function<String, field.type> that works for callers for each complex type)
> On May 13, 2022, at 10:26 AM, David Capwell <dcapw...@apple.com> wrote: > > 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 >> <mailto: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 >
