[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150619#comment-17150619 ]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 7/2/20, 10:46 PM: --------------------------------------------------------------------------- Thanks everyone for making a review/ providing a valuable input/advice. {quote}Has this been considered? {quote} No, it wasn't considered. I did the renaming as per [the agreed plan | https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024] . For the rest of the audience, I reached out [~maedhroz] in Slack to understand better what is the suggestion. The proposed idea is to group parameters in the yaml the way it already happens with the encryption options. *Example:* Moving in the yaml from: {code:java} cached_rows_warn_threshold: 1000 cached_rows_fail_threshold: 16000 {code} {{to:}} {code:java} replica_filtering_protection: - cached_rows_warn_threshold: 1000 - cached_rows_fail_threshold: 16000 {code} *My personal opinion:* if this is really last beta blocker I wouldn't go for a new round of rework and full validation. This patch touches already more than 50 parameters and requires backward compatibility. Every change of the framework requires full validation and discovers new edge cases as those parameters touch all over the code. *My suggestion:* Follow the suggestion for new parameters creation. Implement the suggested refactoring in the next major version. was (Author: e.dimitrova): Thanks everyone for making a review/ providing a valuable input/advice. {quote}Has this been considered? {quote} No, it wasn't considered. I did the renaming as per [the agreed plan | https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17058024&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17058024] . For the rest of the audience, I reached out [~maedhroz] in Slack to understand better what is the suggestion. The proposed idea is to group parameters in the yaml the way it already happens with the encryption options. *Example:* Moving in the yaml from: {code:java} cached_rows_warn_threshold: 1000 cached_rows_fail_threshold: 16000 {code} {{to:}} {code:java} replica_filtering_protection: - cached_rows_warn_threshold: 1000 - cached_rows_fail_threshold: 16000 {code} *My personal opinion:* if this is really last beta blocker I wouldn't go for a new round of rework and full validation. This patch touches already more than 50 parameters and requires backward compatibility. Every change of the framework requires full validation and discovers new edge cases as those parameters touch all over the code. *My suggestion:* Follow the suggestion for new parameters creation. Implement the suggested refactoring in the next major version. > Standardise config and JVM parameters > ------------------------------------- > > Key: CASSANDRA-15234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15234 > Project: Cassandra > Issue Type: Bug > Components: Local/Config > Reporter: Benedict Elliott Smith > Assignee: Ekaterina Dimitrova > Priority: Normal > Fix For: 4.0-alpha > > Attachments: CASSANDRA-15234-3-DTests-JAVA8.txt > > > We have a bunch of inconsistent names and config patterns in the codebase, > both from the yams and JVM properties. It would be nice to standardise the > naming (such as otc_ vs internode_) as well as the provision of values with > units - while maintaining perpetual backwards compatibility with the old > parameter names, of course. > For temporal units, I would propose parsing strings with suffixes of: > {{code}} > u|micros(econds?)? > ms|millis(econds?)? > s(econds?)? > m(inutes?)? > h(ours?)? > d(ays?)? > mo(nths?)? > {{code}} > For rate units, I would propose parsing any of the standard {{B/s, KiB/s, > MiB/s, GiB/s, TiB/s}}. > Perhaps for avoiding ambiguity we could not accept bauds {{bs, Mbps}} or > powers of 1000 such as {{KB/s}}, given these are regularly used for either > their old or new definition e.g. {{KiB/s}}, or we could support them and > simply log the value in bytes/s. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org