[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679241#comment-17679241 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - FYI - just for completeness, posting also here. When I started working on CASSANDRA-18139 I noticed the change is not the output, units are binary since Cassandra 3.6, CASSANDRA-9692. The change done here was to the constants names. More info - CASSANDRA-18139 > 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.1-alpha1, 4.1 > > 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.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656157#comment-17656157 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - I just opened CASSANDRA-18139. We can move any discussions there. > 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.1-alpha1, 4.1 > > 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.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656154#comment-17656154 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Hi [~ifesdjeen], it seems `FileUtils#stringifyFileSize` is used by netstats which I missed when we were revising to revert changes after the discussions raised around CASSANDRA-17863. So yes, I agree with you. I will open a ticket to revert the change later today. Thank you for raising the issue. > 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.1-alpha1, 4.1 > > 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.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656068#comment-17656068 ] Alex Petrov commented on CASSANDRA-15234: - [~e.dimitrova] I realise that this was committed a while ago, but I got a question: there is a small change in output of nodetool commands that use `FileUtils#stringifyFileSize` that might break any parser that relies on the format to be in KB not in KiB etc. This constitutes a regression, doesn't it, as we've set a precedent in -CASSANDRA-17683?- cc [~dcapwell], as we've briefly talked about this. > 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.1-alpha1, 4.1 > > 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.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17509019#comment-17509019 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Doc committed here - https://github.com/apache/cassandra/commit/d67be0def4085863a039d5d3809a9457e883919b > 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.1 > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487801#comment-17487801 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Seems like CCM retagging worked with Jenkins but not with CircleCI anymore. In order CircleCI to pickup the new tag, we need to add -e at the moment. I opened a follow up ticket CASSANDRA-17351 to fix this. Until then, please, use -e. More details sent to the mailing list [here|https://lists.apache.org/thread/x6vojt50z5gcq9n3xfjvgb5cptnh36mz]. > 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.1 > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487629#comment-17487629 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Jenkins failed and I found in the logs the same error. I just restarted the build... Considering that in travis things completed fine now, maybe here the same will happen. I am totally not sure where this came from... I will keep an eye > 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.1 > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487628#comment-17487628 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Ok, travis just completed successfully after the ninja fix. I have no clue why was that error on a line in a file I haven't touched. > 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.1 > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487627#comment-17487627 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - I received an email that travis has failed for cassandra-dtest. It shows me that it failed with syntax error during execution pytest --metatests. I pulled the latest ccm locally and reran that step. It completed fine. In the meantime I saw that I missed to refert to riptano/ccm in requirements.txt. It seems it wasn't in the separate branch as I thought. I just ninja fixed that and I am going to see whether travis will fail again. Jenkins is still running, nothing unusual there for now. > 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.1 > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487621#comment-17487621 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Approvals taken on GitHub and confirmed in Slack. Many rounds of testing on the different commits were executed, but this is the final CI: [j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1337/workflows/38632935-e720-4f5a-85d7-570fc52dbbee] [j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1337/workflows/16bfc433-02fc-4164-ae3a-9d66c577c708] All issues have tickets except the one test that failed on Java 11 but it is some issue with port already occupied which I've seen also with other tests and runs and it is infra related. CCM patch committed [here|https://github.com/riptano/ccm/commit/6d676896fb2ced4b6ac62fdba4ae2570351b38df] and retagged. DTest patch committed [here|https://github.com/apache/cassandra-dtest/commit/3935906a685640b2f6a2058b38fdf45d917edfc9] Trunk patch split to 13 patches starts from [this one|https://github.com/apache/cassandra/commit/db9f7a67ec4b03413c10034956e2cf18739ca4b1] on. Thank you and please don't hate me if Jenkins get down after seeing so many commits :D > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480155#comment-17480155 ] Caleb Rackliffe commented on CASSANDRA-15234: - +1 on fail...we already use "abort" in many situations that relate to transactions > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480032#comment-17480032 ] Benedict Elliott Smith commented on CASSANDRA-15234: +1 for {{fail}} > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479794#comment-17479794 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - The CI lgtm, there are all known failures. The byteman issues appear again but they turned to be general problem with CircleCI. There is already a ticket for investigation. One thing on my mind is - there was a question whether we should use "fail" or "abort" if I am not mistaken. I noticed that only recently "abort" was introduced, "fail" is widely used in our config. I would suggest to stick to "fail" as it is already common for our users. Of course, I will be happy to hear if someone has a different perspective on this topic. Also, my understanding is that [~dcapwell](from offline discussion) and [~maedhroz] are done with their reviews. [~blerer] is swamped at the moment but I want to thank him for all his support and feedback at the early stages. My understanding is [~mck] is about to do a final review and then we can commit when he is ready and of course, I address any potential concerns he might have. I will also do another pass tomorrow as the patch is big and widely spread around the codebase. > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479733#comment-17479733 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - [~maedhroz] I just rebased (both Cassandra and Cassandra-dtest) and pushed the updated as per your review patch. Still keeping things in separate commits for historical purposes until I have a go to squash things. Starting CI here - [j8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1276/workflows/2a49cd4f-d543-4b4c-966b-7cfe0c80f592] and [j11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1276/workflows/39a8545b-b44d-46e9-a374-acc86dbe5da0] > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479134#comment-17479134 ] Caleb Rackliffe commented on CASSANDRA-15234: - [~e.dimitrova] Just reviewed the latest commits and dropped a few comments in the PR. Assuming there isn't anything controversial among them, my +1 stands. (For the {{*_save_period}} items in the virtual table, my guess is just displaying them there in the new format w/ units would be fine.) > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476514#comment-17476514 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - The [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] is ready for final round in my opinion. All three branches - [CCM|https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234], [Cassandra|https://github.com/ekaterinadimitrova2/cassandra/tree/15234-take2-review] and [DTest repo|https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-take2] were rebased and any outstanding issues fixed. +*Exception:*+ * The VT Settings related tests are failing because of the issue I mentioned in my previous comment around _key_cache_save_period, row_cache_save_period and counter_cache_save_period._ * There are a few tests failing with byteman related issues. I suspect CircleCI might be acting weird. The tests complete fine locally. I just pushed a run in Jenkins [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1370/] which I will double check tomorrow. > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17475083#comment-17475083 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - While rebasing and adding more parameters I hit a corner case, three duration parameters without unit suffixes which I personally don't think they need name change. That's fine. A converter was easy to add for them, BUT... what about Virtual tables? In order to support backward compatibility we currently list old parameters, those with new names are available in the old and the new form. For example: {code:java} memtable_heap_space 2018MiB meltable_heap_space_in_mb 2018 {code} The parameters that I personally didn't find a reason to change names but only the value formatting (adding the units to the value) are: _key_cache_save_period, row_cache_save_period and counter_cache_save_period._ I can easily say we introduce a breaking change and leave those alone in the new format but I am open to hear also others' opinion. I feel I am getting too used to this work and I might be missing something. Also, IMHO it's worth it not to introduce breaking changes when possible. In other news during the latest rebase and addition of parameters I found we need to improve the precision for the _DataRateSpec._ I will publish this in a separate patch soon. I am doing last cleaning of tests and I will publish the final version with all latest changes from November until now for the reviewers' consideration. > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470082#comment-17470082 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Moved back to 4.x as the patch has backward compatibility, introducing no breaking changes which aligns with our release discussions. {quote}r on if we allow a single space between values and units. (ex. Allow both {{10MiB }}and {{10 MiB}} {quote} This is very easy to introduce but I think it is confusing to have both, similar to what we decided about the letter case. I would prefer to keep the current version only. Let me know what you think. {quote}bq. The second is trying, where possible, to leave the cases where we throw {{ConfigurationException}} intact. (This mostly applies to the cases where we might throw it via JMX, i.e. we have something of a contract at the moment.) {quote} Good point, I will handle it, thanks. > 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.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17470013#comment-17470013 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thank you [~maedhroz] . I already addressed those on the first two commits, I will address the third commit comments now. Then I will rebase on the latest changes from December and take care of the newest added config in a new commit. I will ping you when I am done. {quote}bq. It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption we are honouring capability or providing a deprecation cycle where appropriate). {quote} In theory we have backward compatibility with the old yaml, no breaking changes which someone might say it qualifies for 4.1. Should I hit the mailing list about that? Also, for general visibility - I opted out of adding new JMX methods as there are already tickets for updating config through Virtual tables people work on and also there is no plan to change nodetool. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469818#comment-17469818 ] Michael Semb Wever commented on CASSANDRA-15234: > Ah, and of course, we'll have to make a decision in terms of whether this > hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to > trunk. It's ok that the patch bumps build.xml to 5.0, if warranted (on the presumption we are honouring capability or providing a deprecation cycle where appropriate). > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469740#comment-17469740 ] Caleb Rackliffe commented on CASSANDRA-15234: - Ah, and of course, we'll have to make a decision in terms of whether this hits 4.1 or not. If it doesn't, it seems like we wouldn't be able to merge to trunk. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17469738#comment-17469738 ] Caleb Rackliffe commented on CASSANDRA-15234: - [~e.dimitrova] I've made my final pass at review and left one more small set of nits inline in the PR. At a high level, there are only two things that linger a bit in my mind. The first, which I've mentioned before, is that we would probably save ourselves some UX trouble later on if we allow a single space between values and units. (ex. Allow both {{10 MiB}} and {{10 MiB}}.) The second is trying, where possible, to leave the cases where we throw {{ConfigurationException}} intact. (This mostly applies to the cases where we might throw it via JMX, i.e. we have something of a contract at the moment.) +1 > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460231#comment-17460231 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thank you [~maedhroz] I made all changes as per the review comments and our discussions. I also left responses on the PR. I have three commits on [this|https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] new PR, as we talked (The old PR stays there, nothing added, nothing squashed; kept for reference) Next round of review on the [new |https://github.com/ekaterinadimitrova2/cassandra/pull/191/files] PR, the following commits: * [the custom types and the related tests|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf]. All tests pass * [The annotations and converters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b] for backward compatibility. I [ran |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1253/workflows/864beb33-9051-4ef7-a96d-4e235fa96e4e] the test suite to ensure any changes in the YAML loader didn't break anything. From what I see the only failures are known ones which after rebase of the patch should go away, most of them. * [The big change |https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3]- all the parameters plus adding backward compatibility for virtual tables. [CI run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1255/workflows/89b0d74c-f745-436a-b2bb-bc7b5ea721e6] Java 8 (I will run again also Java 11 later but there was no reason to waste resources now). The only related to this patch failure is the one of _test_sstablelevelreset ._ I have to adjust the warning pattern in the dtest repo. Side Note: There are two circle ci related commits for testing purposes. Please ignore them at the end. I haven't touched the docs as they will have to be reworked after the migration to adoc. JMX methods convert to the old unit is in there but I will add new JMX method in a separate commit. (There is another ticket linked to this one for that but there was a discussion better to add them here) This doesn't stop the rest of the work from being revised in the meantime. I have to add also that warning we discussed in case some parameters are set more than once in cassandra.yaml. I will do it in a separate commit. After we confirm the current work, I will do new rebase and change any new parameters in trunk to the new format (we still don't have alpha version so it is safe to just change the names and types and no backward compatibility is needed). Order of commits for now should be: 1) Cassandra repo [(the custom types and related tests)|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/c5b19d441949a4bbf0a4395517f8f637b9ee1ddf] 2) Cassandra repo ([The backward compatibility framework |https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/4fda1efee2cb9e01982f79d1aa99ad8fbf8b]) 3) CCM patch 4) dtest patch 5) The [big change of parameters|https://github.com/ekaterinadimitrova2/cassandra/pull/191/commits/6a4cf1d5925da154fd39c35e367fb1aa0f447ca3] > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457271#comment-17457271 ] Caleb Rackliffe commented on CASSANDRA-15234: - CCM changes look reasonable, and I didn't have trouble running a cluster with it against your branch. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456808#comment-17456808 ] Caleb Rackliffe commented on CASSANDRA-15234: - Finished my first pass of review and left comments inline in the PR. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454221#comment-17454221 ] Caleb Rackliffe commented on CASSANDRA-15234: - Note: I think the {{TestClientRequestMetrics}} [failure|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56/jobs/7427] is related to CASSANDRA-17155. With everything rebased, it should wash out. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452661#comment-17452661 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Short update: - I figured out what needs to be done in order to be able to test with our own CCM branch - ticket to update our docs opened CASSANDRA-17182. - I was also thinking of adding a test to the ccm tests but it seems they are not run in CI, not sure what is the story there. ([~mck], any ideas?) - Almost all tests pass now, it seems I have an issue with the assert warnings only, I have to correct the pattern. I did it [here|https://github.com/apache/cassandra-dtest/pull/169/commits/7c417847092524d46de9e03d11d6acc63159e2dd] but I don't think I haven't run whole CI for this. [Java8 CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/345d82ca-1e2a-4db9-b660-a88324793a40] | [Java11 CIhttps://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1239/workflows/d0f8f584-ede1-42f1-96ad-9fbc2d981a56]. This branch was not rebased in the past two weeks so some of the test fixes are no applied. - I will do the JMX change next week in a new commit, it also shouldn't bother any reviews to happen in the meantime if/when people are available. I know [~dcapwell] and [~blerer] are busy and also holidays are approaching. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452143#comment-17452143 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Quick update - I figured it is purely pip3 issue how we install ccm. The time things worked was when I had a bug in my code, but in general CCM is not changing to my new version when I change it in requirements.txt What I found in CircleCI logs: {code:java} Collecting ccm Cloning https://github.com/ekaterinadimitrova2/ccm.git (to revision CASSANDRA-15234) to /tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2 Running command git clone -q https://github.com/ekaterinadimitrova2/ccm.git /tmp/pip-install-dvfww32x/ccm_727b34808faa4db6904e104a715a22d2 Running command git checkout -b CASSANDRA-15234 --track origin/CASSANDRA-15234 Switched to a new branch 'CASSANDRA-15234' Branch 'CASSANDRA-15234' set up to track remote branch 'CASSANDRA-15234' from 'origin'. Resolved https://github.com/ekaterinadimitrova2/ccm.git to commit ee52d120ea34d44500c64bfb3b9d3f517b0865f1 {code} But then {code:java} pip3 freeze {code} output shows: {code:java} ccm @ git+https://github.com/riptano/ccm.git@ce612ea71587bf263ed513cb8f8d5dfcf7c8dadb {code} > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451939#comment-17451939 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Moving the ticket to "In Review" as [~dcapwell] is already looking into it. Also, for visibility and context as it seems I missed in my summary - there is a separate ticket linked to this one(CASSANDRA-9691) which was mentioning liberating metrics and JMX from units or just moving to lowest unit at least. I left this part to be handled there but I forgot to mention it in my summary. Apologize for that My thought was currently to leave the JMX for now and assume the old units are in place but [~dcapwell] is right we need at least to verify and convert if needed that in Config the old unit was used with the new custom types and we didn't use something different as this can be a mess if we live it to people and reading docs. Something similar will also be needed for VTs where we will have to check the Converter in the new @Replaces annotation. There was idea for getting the VT backward compatibility out until we figure out how we are going to handle the VT as there is ongoing discussion around that, I will leave this now aside for a moment until we clear a bit the discussion. CC [~blerer] as I know he is working on a patch for CASSANDRA-15254 Also, I will be looking again into the ccm issue in the afternoon. > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451448#comment-17451448 ] David Capwell commented on CASSANDRA-15234: --- bq. DTests were not updated to the new names and format as this will take forever. Suggestion - leave the old ones and add new tests with new ones. We can also open a follow up ticket but now this exercises the backward compatibility which is good as this is also how I figured out one more change needed for CCM. works for me; more testing we didn't break things ^_^ bq. I suggest not to overwhelm the patch with the reorganization of cassandra.yaml I suggested earlier on this ticket. I will pull it in a separate one and I can trigger a new discuss thread on the mailing list to confirm that. Works for me bq. Converter was not changed to an enum because we need generics support for that and JEP301 was withdrawn. Works for me bq. Intentionally left the commits after the old patch not squashed to provide some input and hopefully make the review a bit more easy. Benjamin Lerer and David Capwell , please, let me know if you want them in a different way for the review. Personally prefer PRs, easier to leave comments than commits bq. Any new parameters added post 4.0 in trunk were/will be directly changed to support the new format as they are still not in any release. Saw the TrackWarning changes <3 bq. I can think of adding some additional test for the virtual table. I am 100% cool leaving the vtable problem to another ticket =). Right now it will show the new names, if we want different behavior we can solve it outside of this JIRA. We are having side conversations on how can we unify (at least I am pushing this) properties access. bq. I also suggest we add a warning to the users when they start Cassandra that if they add more than once a property (even if it is the old name), the latest occurrence from the yaml file will be the one assigned to the parameter. I would say we add also info to the docs and we don't complicate to add checks whether we have or not more occurrences during startup and emitting warnings on occurrence as it seems a bit too much overhead on startup. WDYT? Ideally I like this, but also 100% cool not doing in this patch. {code} a: b a: c {code} that has worked for years without anyone noticing... if adding a warning is low-hanging-fruit then I am cool, but I wouldn't hold up this ticket (I like splitting tickets if you have not noticed). > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451447#comment-17451447 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Sure, [PR|https://github.com/apache/cassandra/pull/1350] created > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17451443#comment-17451443 ] David Capwell commented on CASSANDRA-15234: --- patch is massive; no way I can finish before I go on break Friday =( Can you actually send a PR? easier to leave comments > 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: 5.x > > 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.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447181#comment-17447181 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - I have some issue that I can't always trigger to get the newest version I push to ccm. Still it seems Jenkins has more success than CircleCI. Until I figure it out, these are the patches for initial round of review. [trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-take2?expand=1] | [dtest|https://github.com/ekaterinadimitrova2/cassandra-dtest/pull/new/CASSANDRA-15234-take2] | [ccm|https://github.com/ekaterinadimitrova2/ccm/pull/new/CASSANDRA-15234] I cleaned all tests without full Jenkins confirmation of the dtests yet due to the ccm issue mentioned. Also, this patch latest rebase was also a week ago and I will rebase again when I have to do next round of review changes and I fix ccm as otherwise on every rebase something new appears as trunk is quite alive and the config is all over the place. Let me first stabilize CI and we can agree on the patch, then I will clean this. Now a few important comments: * ASCII doc migration is still not done but I will open a ticket to add docs for us for adding new config and docs for our users around the new and old types and names. * DTests were not updated to the new names and format as this will take forever. Suggestion - leave the old ones and add new tests with new ones. We can also open a follow up ticket but now this exercises the backward compatibility which is good as this is also how I figured out one more change needed for CCM. * CCM was updated to be able to handle the backward compatibility and Cassandra behavior. * I suggest not to overwhelm the patch with the reorganization of cassandra.yaml I suggested earlier on this ticket. I will pull it in a separate one and I can trigger a new discuss thread on the mailing list to confirm that. * Converter was not changed to an enum because we need generics support for that and [JEP301|http://openjdk.java.net/jeps/301] was withdrawn. * Intentionally left the commits after the old patch not squashed to provide some input and hopefully make the review a bit more easy. [~blerer] and [~dcapwell] , please, let me know if you want them in a different way for the review. * Now when 4.0 was released I had to add also Virtual Table backward compatibility and the easiest way was just to have the old names and types and the new ones both listed in the Settings table. * commitlog_sync_batch_in_ms was left for another ticket as the in-jvm upgrade tests will need work to make it possible to support it due to their nature as it seems we have the lower branch DatabaseDescriptor class loaded and it makes checks on trunk and complains if we change to the custom type. * Any new parameters added post 4.0 in trunk were/will be directly changed to support the new format as they are still not in any release. * CCM_41_YAML_OPTIONS in ccm should be well documented and people warned that they need to keep it up to date on changes in config. I hope we won't need this to happen a lot after this update but we need to ensure people are aware of it. It seems a bit clumsy but I didn't find a better way to handle ccm at this point. Open for ideas. * I can think of adding some additional test for the virtual table. * I also suggest we add a warning to the users when they start Cassandra that if they add more than once a property (even if it is the old name), the latest occurrence from the yaml file will appear. I would say we add also to the docs and we don't complicate to add checks whether we have or not more occurrences and on occurrences adding it as it seems a bit too much overhead on startup. WDYT? * There were deprecation warnings emitted more than once. I fixed this. This fix should be also ported to 4.0 where we had to make small port of the name change because of two parameters issues. (FTR - CASSANDRA-17141) > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17435713#comment-17435713 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Rebase and cleaning done successfully. I cleaned Unit tests and distributed In-jvm tests, passing up to current trunk state. I should finish updating the Python DTests for the new config parameters' names and check for failures when the java upgrade tests are fixed. Topic: * the upgrade tests will be testing with the new names and config parameters provided with the units for trunk. We have unit tests that check the backward compatibility parsing. I guess we don't plan to run the upgrades also with the old config? I plan to publish the full patch for new round of review probably early next week. > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433798#comment-17433798 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - For the record, this is the discussion thread from the dev mailing list - [https://lists.apache.org/thread.html/r507be1624a568765f9d5ec5f6b561885129d0aaeb982e9bd9bf5e01b%40%3Cdev.cassandra.apache.org%3E] Based on it, I am getting back to this work. > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383461#comment-17383461 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thank you [~benedict] and apologize for the late response. There was a lot of multitasking lately. {quote}it would be good to get some initial feedback on this approach to grouping of config options, as optimising the groups is a laborious job that there's no point pursuing if it's otherwise unwelcome. {quote} Absolutely agree with you. I personally have only that question for feedback, whether they would prefer the sections or the nested version you suggested. [~maedhroz], [~mck], [~paulo], [~blerer], [~dcapwell], [~lor...@datastax.com] (maybe [~stefan.miklosovic] as I know he was also interested into this work at some point) - do you have anything to add here as concerns/comment before we bring it to the user list? Also, should it come from a PMC? Survey or just a discussion mail thread? I am not familiar of any similar discussions before so I am not sure what would be the right approach, I am open for suggestions/advice anyone might have. Thank you. > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376671#comment-17376671 ] Benedict Elliott Smith commented on CASSANDRA-15234: So, I produced an initial proposal [here|https://github.com/belliottsmith/cassandra/blob/5f80d1c0d38873b7a27dc137656d8b81f8e6bbd7/conf/cassandra_nocomment.yaml] in [this comment|https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17162342=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17162342]. It is not complete, but the shape of the idea is pretty clear, I think - it would be good to get some initial feedback on this approach to grouping of config options, as optimising the groups is a laborious job that there's no point pursuing if it's otherwise unwelcome. We can no doubt bike shed those to death as well, if we so choose. > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376655#comment-17376655 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Reading back the thread here and reminding myself of what we discussed I guess the next step is to hash a proposal for the user list and get some feedback? {quote}bq. I'd personally prefer to hash out here for a week or so, to get a good proposal to take to the user list, or a couple of competing proposals. I find public engagements works best when there's a good case to challenge/consider. {quote} > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374817#comment-17374817 ] Benjamin Lerer commented on CASSANDRA-15234: Changing the status to {{IN PROGRESS}} as the current patch need to update once we agree on the expected outcome. > 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: 5.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209560#comment-17209560 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thanks [~benedict]. I think maybe it is a matter of Jira permissions. My only option is to select only from a list of already created versions. > 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: 5.0 > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209537#comment-17209537 ] Benedict Elliott Smith commented on CASSANDRA-15234: Not sure if you need special permissions, but you can just create a new 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: 5.0 > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209532#comment-17209532 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - +1 Changed the version to 4.x only because there is no 5 yet. If there is other way to mark it that I missed, please, feel free to correct me :) > 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.x > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209519#comment-17209519 ] Paulo Motta commented on CASSANDRA-15234: - bq. I am fine postponing this ticket but the next target for it should be 5.0 in my opinion not 4.X. +1, I actually meant next major by 4.X > 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, 4.0-triage > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209355#comment-17209355 ] Benjamin Lerer commented on CASSANDRA-15234: {quote}In the spirit of expediting 4.0RC release I propose we postpone this to 4.X, and resume this with high priority earlier in the next release cycle.{quote} This is a major configuration change. As such, it should be part of a {{major}} release and not of a {{minor}} one. I am fine postponing this ticket but the next target for it should be {{5.0}} in my opinion not {{4.X.}} > 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, 4.0-triage > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209288#comment-17209288 ] Caleb Rackliffe commented on CASSANDRA-15234: - bq. In the spirit of expediting 4.0RC release I propose we postpone this to 4.X, and resume this with high priority earlier in the next release cycle. I'm more or less in agreement that we push this to 4.x along with CASSANDRA-16038, unless some unrelated need for the latter arises. > 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, 4.0-triage > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204374#comment-17204374 ] Jon Meredith commented on CASSANDRA-15234: -- The improvements are definitely very valuable and make configuration much cleaner and more flexible, but I'm also concerned it's too late in the cycle. Although the patch goes to great lengths to be backward compatible, people that have been working towards getting ready for production deployments would need to re-test all the configurations they've worked through so far which would certainly cause rework to validate the release. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203910#comment-17203910 ] Paulo Motta commented on CASSANDRA-15234: - Despite the awesome work (thanks for leading it [~e.dimitrova]) and productive discussion that went into this issue, we didn't seem to reach a strong agreement here and it seems to me it's a bit late in the 4.0 release cycle to land this? In the spirit of expediting 4.0RC release I propose we postpone this to 4.X, and resume this with high priority earlier in the next release cycle. What do you think? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171797#comment-17171797 ] Caleb Rackliffe commented on CASSANDRA-15234: - bq. Maybe we can only create now a separate new ticket on the in-jvm api change so a snapshot release could be voted, etc. [~e.dimitrova] I like that idea. I'd volunteer to review a separate Jira... > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164627#comment-17164627 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - [~benedict] I am sorry for my delayed responses but I am multi-tasking a lot these days. {quote}I'm fairly certain the main body of this work should be utilised to support whatever our new config file layout is; whether we commit it first or all together is fine by me, and I'm happy to defer to others' preferences (most importantly yours, as the author) {quote} I think the backward compatibility is the primary part that will be most probably reworked to accommodate the new approach. I think the moment we moved the ticket to beta and the discussion continued here, that was the time we kind of agreed through our actions that this work will be continued/completed/committed later. I might have gotten it wrong. As it looks like this is already happening, I suggest to shape it and then move on with the actual changes. Maybe we can only create now a separate new ticket on the in-jvm api change so a snapshot release could be voted, etc. But also, we need to see what yaml nodes will have to be created according to what we need, so that work could also wait a bit until the api part is agreed, I think. About the dual approach, I am not sure I understand you correct what you mean in this citation: {quote}providing us a simple route to permitting common options being given at the start of the file, without confusing the overall approach. {quote} I understand having third version will help any simplistic tools in case they can't deal with the nested approach but to me personally it would be confusing. I am pretty sure [~lor...@datastax.com] will update perfectly the documentation (as usual, thanks a lot [~lor...@datastax.com]!) but at the same time if someone is in a hurry during a production issue, they will just jump on random link probably and maybe be get confused about what/how. Here, for this part, probably the survey will show the best. Otherwise, the grouping sounds reasonable to me. The reason why I suggested Quick Start, Advanced options etc is new users. I kind of feel that for someone brand new to C* this might help. But also if we make groups into nested parameters, sure this becomes irrelevant and those sections will not really make sense anymore. Excited to see the end result/user reactions. Last but not least, I also agree with you on the below: {quote}I'd personally prefer to hash out here for a week or so, to get a good proposal to take to the user list, or a couple of competing proposals. I find public engagements works best when there's a good case to challenge/consider. {quote} > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163071#comment-17163071 ] David Capwell commented on CASSANDRA-15234: --- bq. I'd personally prefer to hash out here for a week or so, to get a good proposal to take to the user list, or a couple of competing proposals. I find public engagements works best when there's a good case to challenge/consider. +1 bq. I will be happy to write clear information about this topic in the docs after implementation, to explain old/new. Thats great Lorina! > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162346#comment-17162346 ] Lorina Poland commented on CASSANDRA-15234: --- I will be happy to write clear information about this topic in the docs after implementation, to explain old/new. Lorina Lorina Poland e. lor...@datastax.com w. www.datastax.com On Tue, Jul 21, 2020 at 2:09 PM Benedict Elliott Smith (Jira) < > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162342#comment-17162342 ] Benedict Elliott Smith commented on CASSANDRA-15234: bq. it would be great to start this dialog on user@ I'd personally prefer to hash out here for a week or so, to get a good proposal to take to the user list, or a couple of competing proposals. I find public engagements works best when there's a good case to challenge/consider. It's a difficult balancing act getting any given approach right, and there are multiple approaches. I would love to see another approach taken more to its conclusion for comparison. I've made some further changes, and to make it clearer created a [yaml|https://github.com/belliottsmith/cassandra/blob/acac38be9f528e380974423b86fad5e895e3/conf/cassandra_nocomment.yaml] with comments mostly stripped. In this version, there are basic settings for network, disk etc all grouped together, followed by operator tuneables mostly under {{limits}} within which we now have {{throughput}}, {{concurrency}}, {{capacity}}. This leads to settings for some features being kept separate (most notably for caching), but helps the operator understand what they have to play with for controlling resource consumption. It's still incomplete, but 90%+ done, and thoughts would be most welcome. > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162271#comment-17162271 ] Benedict Elliott Smith commented on CASSANDRA-15234: Thanks [~e.dimitrova] bq. If you decide at some point this work or part of it to be committed It was a confusing disagreement, certainly. I understood us to have agreed that - if wanted - we could commit the work that's been reviewed, excluding only the new config file (and the new config parameter name tests etc). It's up to you of course. I think there could be value in this, since it might make the config file change more manageable, but I'm personally neutral on sequencing. I'm fairly certain the main body of this work should be utilised to support whatever our new config file layout is; whether we commit it first or all together is fine by me, and I'm happy to defer to others' preferences (most importantly yours, as the author) > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162209#comment-17162209 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Good catch [~benedict] . Thank you. My bad, just pushed a fast commit [here|https://github.com/ekaterinadimitrova2/cassandra/commit/b4eebe080835da79d032f9314262c268b71172a8] for the three rate parameters we have. For the record, I stopped working on this patch until it is clear whether the code will be used at all. As far as I understand, you took the lead on a POC development for the newly suggested approach. Unfortunately, I don't have time to support this now but I would be happy to give feedback when it is shaped already. If you decide at some point this work or part of it to be committed, let me know, I will complete whatever is outstanding. The main framework is in place. A couple of things to keep in mind: * As suggested by Benjamin, the patch can be simplified by making {{Converter}} an {{enum}}. It will allow to use the enum value directly into the {{Replaces}} annotation. Doing so will remove the need to use reflection to instantiate the converters and the use of a cache to avoid multiple instantiation. * In-jvm tests - loading config parameters should be reworked as currently they don't work with custom types (like the newly introduced Duration, etc). The suggested approach by [~dcapwell] would work but it requires also api changes. I suggest a separate ticket for this part to be opened. Instead of using reflection, the suggestion is to use SnakeYAML. In order not to slow down the tests, no yaml files will be introduced but there will be a function to build the yaml nodes for us. This was a quick POC by [~dcapwell] but there are parameters which will need additional work and attention: public class MapToConfigTest { @Test public void test() { Map map = ImmutableMap.builder() .put("auto_bootstrap", false) .put("permissions_validity_in_ms", 10) .put("role_manager", "some value") .build();Constructor constructor = new YamlConfigurationLoader.CustomConstructor(Config.class); PropertiesChecker propertiesChecker = new PropertiesChecker(); constructor.setPropertyUtils(propertiesChecker); constructor.setComposer(new Composer(null, null) { public Node getSingleNode() { return toNode(map); } });Config config = (Config) constructor.getSingleData(Config.class); System.out.println("trap"); }public static Node toNode(Object object) { if (object instanceof Map) { List values = new ArrayList<>(); for (Map.Entry e : ((Map) object).entrySet()) { values.add(new NodeTuple(toNode(e.getKey()), toNode(e.getValue(; } return new MappingNode(FAKE_TAG, values, null); } else if (object instanceof Number || object instanceof String || object instanceof Boolean) { return new ScalarNode(FAKE_TAG, object.toString(), FAKE_MARK, FAKE_MARK, '\''); } else { throw new UnsupportedOperationException("unexpected type found: given " + object.getClass()); } }private static final Tag FAKE_TAG = new Tag("ignore"); private static final Mark FAKE_MARK = new Mark("ignore", 0, 0, 0, "", 0); } The rest are small things which I also partially already handled. [~maedhroz], [~benedict], please, let me know if you have any other questions around this patch. > 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-beta > > 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}}. >
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17160264#comment-17160264 ] David Capwell commented on CASSANDRA-15234: --- Thanks [~maedhroz] and [~benedict] for the YAML examples; it would be great to start this dialog on user@ to get peoples feedback. bq. I personally would like to propose we also introduce a dual system for updating properties, wherein we can accept the nested namespace versions, as well as e.g. dot-delimited versions. e.g. disk.throttle.compaction: 10MiB/s. This should mitigate any risk to simplistic tools, as well as maybe providing us a simple route to permitting common options being given at the start of the file, without confusing the overall approach. So the following would be supported? {code} compaction_throughput_mb_per_sec: 42 disk: throttle: compaction: 42MiB/s disk.throttle.compaction: 42MiB/s {code} I assume the semantics would require mixed to work (part of the disk.throttle is nested, other parts are not) and wouldn't allow duplication definitions with other versions (can only use 1 of the 3 forms, not all), so doesn't seem that bad as that logic already exists. We walk the class to discover the previous names, so can do the same or collect the shape while we walk. My main concern is if this makes it more confusing for users; they may find some docs which say the old name, some using the nested name, and others using the flat name. > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159846#comment-17159846 ] Benedict Elliott Smith commented on CASSANDRA-15234: Thanks Caleb for the reminder. I've pushed another approach, that groups options by the reason the operator cares about them, namely: {{cluster}}-wide settings (partitioner, token etc), {{disk}} options that specify strategy, throttle throughput etc, {{memory}} options that allocate heap or direct memory resources, {{concurrency}} that constrain the number of operations or threads committed to tasks, {{internode}} and {{client}} networking options, {{feature}} options and {{log}} options for our warning thresholds etc. It was taking a while, and it might not be well received, so I only went about 90% of the way so that the approach can receive some feedback. Obviously, this would necessitate a different approach to the headline comments, wherein we might want to list the parameters users might care about in prose alongside explanations for why they might care. I personally would like to propose we also introduce a dual system for updating properties, wherein we can accept the nested namespace versions, as well as e.g. dot-delimited versions. e.g. {{disk.throttle.compaction: 10MiB/s}} [~e.dimitrova]: in going through the yaml, I noticed that you have used mbps in many places, but I thought we had previously agreed that any {{bps}} was ambiguous, since it can mean bits or bytes? I thought we had settled on MiB/s so that there could be no ambiguity? (Since MB/s is also ambiguous - technically meaning 1000s, but often meaning powers of 2)? > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17159688#comment-17159688 ] Caleb Rackliffe commented on CASSANDRA-15234: - [~e.dimitrova] [~benedict] I've posted [a rough sketch|https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8] of what a fairly aggressive application of option grouping would look like for {{cassandra.yaml}}. Hopefully that helps keep the conversation moving forward... > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17157935#comment-17157935 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - [~maedhroz] pointed to me correctly that the new yaml was missing at the last submitted branch as I was testing the backward compatibility with the old cassandra.yaml. [This | https://github.com/ekaterinadimitrova2/cassandra/commits/CASSANDRA-15234-new2] is a link to a WIP branch where the new yaml could be found. The last two commits are respectively the change to a new structure and the change of parameters names. > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152607#comment-17152607 ] Benedict Elliott Smith commented on CASSANDRA-15234: bq. would you mind starting the discussion on the dev list? Happy to get more directly involved to move this along, if you like. In this case I will put together a specific proposal to bring to the dev list, to avoid it being an aimless discussion. > 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-beta > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152593#comment-17152593 ] Benjamin Lerer commented on CASSANDRA-15234: {quote}Can we mark this ticket and the grouping one as non-blocking for beta{quote} I will do that. {quote}Can we start the conversation and start asking operators of Cassandra clusters on their thoughts on grouping vs not grouping? Grouping could be nice for humans but could be horrid for some automation (I am neither pro or against grouping, I defer to operators preference here).{quote} [~benedict], [~maedhroz] as you are the ones that suggested the change, would you mind starting the discussion on the dev list? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152590#comment-17152590 ] Benedict Elliott Smith commented on CASSANDRA-15234: bq. We can ... not deprecat[e] the old API and not announc[e] ... the new API This would be fine by me. My -1 as expressed applied only to the public API changes. All of the other changes in this ticket are absolutely good to go (once review is completed, of course). Also to reiterate again (since things easily get lost in such a contentious exchange): * I think this work is great, and am really glad [~e.dimitrova] undertook it. * I don't personally mind too strongly _which_ API we settle on, just expect that we settle on one upfront before committing the userbase to it. * I think it's a shame that this has seemingly turned into a heightened and acrimonious exchange. * It's worth remembering this situation is not unique; we have all experienced having to revisit work (or abandon it, even - my GitHub is a graveyard of good intentions) to our frustration and disappointment; it's a part of OSS development. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152266#comment-17152266 ] David Capwell commented on CASSANDRA-15234: --- Reread the conversations that have been going on over the past 3 days several times, sorry if I missed anything or didn't grasp all points. Most of the thread is about doing an all or nothing approach, thanks [~mck] for trying to argue for incremental improvement. Looking at the list of properties impacted (see https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-new#diff-4302f2407249672d7845cd58027ff6e9R257-R339) it looks like a subset would be clearly impacted by the grouping approach, and others not so much or are complementary; given this we could accept a hand full of the properties and move the other properties into the grouping work (stuff such as read_request_timeout_in_ms to read_request_timeout I feel are fine even with the grouping approach, but stuff which renames things maybe leave out for now, such as enable_user_defined_functions to user_defined_functions_enabled). I do agree with [~benedict] that it isn't ok to keep changing our config API since this is user facing, we should be strict about user facing changes and try to help more than harm. If there is a belief that one structure is better than another then I value this dialog and hope we can get more eyes from the users/operators to see their thoughts; for this work we should really speak about the YAML representation rather than the code so we can agree on the final result. Also, given the framework that is provided by this patch, I don't see that work as throwing everything away, instead I see it benefiting from the work which is started. Given the work involved is to add support for "moving" a field (current "rename" is a special case of move where the move is at the same level) from one location to another (rename and conversion already supported), this adds complexity for the case where the new and the old field are both used and may hit complexity issues with SnakeYaml implementation. I do believe we should have this discussion and settle on a solution before releasing 4.0.0, but I do not feel that this discussion blocks a beta release. There is a lot of chatting about being a beta blocker but I don't really follow why this JIRA (or the grouping one) is a blocker. Reading https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle I don't see why this JIRA could not be done during beta, it meets every requirement for this phase. Given all the comments above, my TL;DR * Can we find a subset of properties with the current patch which are not discarded by the grouping work (sample given above) * Can we start the conversation and start asking operators of Cassandra clusters on their thoughts on grouping vs not grouping? Grouping could be nice for humans but could be horrid for some automation (I am neither pro or against grouping, I defer to operators preference here). * Can we mark this ticket and the grouping one as non-blocking for beta > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152252#comment-17152252 ] Michael Semb Wever commented on CASSANDRA-15234: {quote}I am fine to be proved wrong in a justified way. Benedict Elliott Smith, Benjamin Lerer, Michael Semb Wever, do you agree with me on my suggestion(reorganizing the yaml file and doing the nested parameters approach later)? {quote} Let's keep listening to what everyone has to say. Some of us are better with the written word than others, it is a second language for some, and for me as a native-english-speaker it is still all too easy to miss things the first time they are said. On that, I believe everyone hears and recognises what [~e.dimitrova] is saying here regarding frustrations about such a substantial change being suggested so late in the game and the amount of time that's been asked to re-invest. Especially when an almost identical user experience improvement was presented two months ago. But it should be said again. On a side-note, it would have really helped me a lot if the comment above back-referenced [this discussion|https://github.com/apache/cassandra/pull/659#discussion_r449201020] where it originated. I know the ticket was referenced, but that discussion thread is the source of the suggestion. {quote}This ticket’s API replaces the current API, is mutually exclusive with the alternative proposal, and would be deprecated by it. If we introduce them both in 4.0-beta, we must maintain them both and go through the full deprecation process. So unfortunately no churn is avoided. {quote} AFAIK this is the only "grounded" justification for the veto. I don't agree that we are forced into that premise. We can get around those compatibility rules with a minimal amount of effort, by not deprecating the old API and not announcing (in docs or yaml) the new API. (I would expect everyone to intuitively treat private undocumented and un-referenced APIs, only ever available in alpha and beta releases, to be considered unsupported.) All that "compatibility change" can be left and just done once in the separate ticket. The underlying framework and bulk of this patch can still be merged. Based on that I see three possible courses of action: 1. Accept investigating the alternative proposal, and include it in this ticket, delaying our first 4.0-beta release, 2. As (1) but requesting this ticket to be merged during 4.0-beta, so we can release 4.0-beta now, 3. Spin out the new suggestion and all public API changes to a separate ticket, slated for 4.0-beta, and merging this ticket. I suspect, since you have offered to help [~benedict], that most are in favour of (2) ? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152224#comment-17152224 ] Caleb Rackliffe commented on CASSANDRA-15234: - My mental model of why grouping _might_ be valuable: * It provides a logical place to describe/comment on entire features in the YAML. * It avoids duplicate prefixing without sacrificing intelligibility/specificity. * It doesn't rely on the presence of comments. My understanding of the changes here is that there are dozens of options that have already been renamed. Assuming we proceed with grouping, supporting three different forms of these options doesn't seem like the outcome we want. There are really only a handful of groupings that would be interesting and obvious. Essentially, hinted handoff, commitlog, memtable, rpc, compaction, and maybe the caches. (Timeouts seem a bit scattered.) What I'm most worried about is the number of versions we have to support at any given time, not whether we change some option grouping early in the beta period. My vote, at this point, would be to just move this issue to beta and hash out a proposal for the (somewhat obvious) option groups I've mentioned above. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152159#comment-17152159 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Apologize for my late response. I was a bit sick these days and tried to disengage from work and take some rest over the weekend. With all my respect to everyone's opinion and experience on the project, I have two points here: - I truly support [~mck]'s questions. I believe they should be responded before any decision is taken and someone jumps into actual work. {quote}how many settings does it apply to? is taxonomy based on a technical or user perspective? if user/operator based, how many people need to be involved to get it right? if user/operator based, what if one property applies to multiple concerns? how does the @Replace annotation work between levels in the grouping? does this introduce more complexity/variations in what has to be tested? (since yaml can consist of old and new setting names) {quote} - I was also wondering today while I was trying to be open-minded and look from all perspectives at this ticket/patch... Did anyone check the first [commit |https://github.com/ekaterinadimitrova2/cassandra/blob/CASSANDRA-15234-1-outdated/conf/cassandra.yaml] where I was suggesting reorganizing of the text into the yaml into sections? I also put it into the ticket thread. This was a quick draft shared two months ago that could be reworked to sections that satisfy the users' requirements for clarity and consistency. Do we see any big difference for the users between: {code:java} #*Replica Filtering Protection* cached_rows_warn_threshold: 1000 cached_rows_fail_threshold: 16000 {code} and: {code:java} replica_filtering_protection: - cached_rows_warn_threshold: 1000 - cached_rows_fail_threshold: 16000 {code} >From that perspective, I think the C* community can accept this patch and then >we can raise a new ticket) to improve the internals from our engineering >perspective in Beta(refactoring the Config class and the backward >compatibility framework), as suggested by [~mck]. I think this work could be >really considered incremental work. Having that in mind, honestly, I don't find a justification to spend my time to rework and fully re-test the patch at this point in time. I am fine to be proved wrong in a justified way. [~benedict], [~blerer], [~mck], do you agree with me on my suggestion(reorganizing the yaml file and doing the nested parameters approach later)? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152110#comment-17152110 ] Benedict Elliott Smith commented on CASSANDRA-15234: > There are no true urgency to fix that ticket so if we want to go the grouping > way within the scope of that ticket we should move it to 4.X. I think this is indeed preferable to releasing an API we already expect to deprecate, however I think we're overstating the difficulty here. We haven't debated the parameter naming much at all, and we can easily land this in 4.0-beta. If [~e.dimitrova] doesn't have the time, and 4.0-beta is an acceptable window to land the work, I can take a look in a few weeks. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152103#comment-17152103 ] Benedict Elliott Smith commented on CASSANDRA-15234: > We have un-tested beliefs about a potentially superior design We don't ordinarily label our judgements about design "un-tested beliefs" and I think it would help to avoid this kind of rhetoric. If we all start labelling design decisions in this way the project might grind to a halt. I have anyway tried specifically to sidestep this kind of accusation, by leaving the ball in your court. I am simply asking those pushing to move ahead with the current proposal to endorse the view that it is superior. This is a very weak criteria to meet, and involves no beliefs external to yourselves. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152102#comment-17152102 ] Benjamin Lerer commented on CASSANDRA-15234: Argeeing on grouping will take a significant amount of time. Specially now where a lot of people are pretty busy with other tasks. There are no true urgency to fix that ticket so if we want to go the grouping way within the scope of that ticket we should move it to 4.X. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152050#comment-17152050 ] Josh McKenzie commented on CASSANDRA-15234: --- {quote}{color:#172b4d}It is customary that, before work is committed, alternative proposals are engaged with on their technical merits. It occurs to me we recently worked to mandate this as part of the process, in fact. In this case we {color}_seem_{color:#172b4d} in danger of subordinating this to beliefs about scheduling.{color} {quote} {color:#172b4d}Unfortunately it's customary on this project to do that right up until the last moment before something is committed (and even beyond) with no weighting of the value on things actually being in the hands of users vs. in tree and unreleased.{color} {color:#172b4d}We have un-tested beliefs about a potentially superior design against un-tested beliefs about the negative impact of the project on further delay. This is not a situation in which we can expect to make progress on a discussion until and unless both sides collect some empirical evidence about their position as well as spend real time investigating and exploring the position of other people engaged.{color} {color:#172b4d}Unfortunately I'm well past the time I personally have available to engage on this ticket; I'll defer to other people to take it from here.{color} > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151948#comment-17151948 ] Benedict Elliott Smith commented on CASSANDRA-15234: bq. The valid concern around the api churn it introduces is addressed by committing the new ticket to 4.0-beta. This ticket’s API replaces the current API, is mutually exclusive with the alternative proposal, and would be deprecated by it. If we introduce them both in 4.0-beta, we must maintain them both and go through the full deprecation process. So unfortunately no churn is avoided. > I'd be curious what your perspective is on how we determine what qualifies as > justified It is customary that, before work is committed, alternative proposals are engaged with on their technical merits. It occurs to me we recently worked to mandate this as part of the process, in fact. In this case we _seem_ in danger of subordinating this to beliefs about scheduling. If you like, I can formulate a legally airtight veto, but my goal is only for you to engage briefly with the proposal and determine for yourselves which is superior. If the new proposal is _technically_* superior, and of similar complexity, then you are my justification. If you disagree, however - and importantly we agree that we do not intend to pursue the alternative approach in future - I would consider my veto invalid (and would anyway withdraw it). > having heard of the proximity of the beta Perhaps we can also directly address people’s thoughts on deferral to 4.0-beta? This should surely alleviate concerns around delaying 4.0? I do understand the imperative to get 4.0 out the door, but I also know we all want to ship the best product we can as well. If we can achieve both, we should. APIs matter, and avoiding API churn is an important part of our user/operator story. * I _hope_ we can avoid an epistemic battle about the word "technical," and accept that API design is a technical endeavour to convey meaning. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151396#comment-17151396 ] Michael Semb Wever commented on CASSANDRA-15234: I'm struggling to see how a request to break work down into separate tickets and steps constitutes a technical reasoning that should block the work. The valid concern around the api churn it introduces is addressed by committing the new ticket to 4.0-beta. The more we can do incrementally the better. From reviewing, to testing, to the compartmentalising of jira ticket discussions. (I still miss jira comment threads, even if folk never really used them consistently.) bq. … everyone has since agreed (or implied) this is a superior approach. Not on my behalf. And I don't believe all others presumed answers to all questions that need to be asked for it to be a validated proposal. For my part, it is a good suggestion that warrants further investigation. It still needs to be investigated and spec'd out. bq. If we change our minds and agree the current approach is the final and superior solution, that is another matter. Not sure I agree with the onus here, based on this being an un-investigated and un-specified suggestion. The onus I think should be the opposite: those wanting this to be a blocker should do the work in determining the value (investigation) and design (specification) to the suggestion. The suggestion is not a fault or bug in this ticket, there is nothing in the suggestion that *breaks* the patch, it is imho rather a subsequent suggested improvement. Even if it was a suggestion that replaced this patch it should be dealt with in the same way. And of course making such a suggestion first here is natural because the author _may_ take it on in-stride, but it should be the author's prerogative to request it be "the next step". In a new ticket: we can better investigate the value that grouping brings and other questions like… - how many settings does it apply to? - is taxonomy based on a technical or user perspective? - if user/operator based, how many people need to be involved to get it right? - if user/operator based, what if one property applies to multiple concerns? - how does the {{@Replace}} annotation work between levels in the grouping? - does this introduce more complexity/variations in what has to be tested? (since yaml can consist of old and new setting names) > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151344#comment-17151344 ] Josh McKenzie commented on CASSANDRA-15234: --- {quote}bq. To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution for a public API. It is user unfriendly. {quote} We as a project need to mindfully balance when something is "good enough" and when the trade-off is in favor of getting a release out vs. pursuing another incremental improvement to an API. In my opinion this is classic bike-shedding. Given a day focused on nothing but thinking of how to improve our config API I firmly believe we could come up with something that a simple majority considered an improvement over what's proposed on this ticket + config grouping in a vacuum. _I personally prefer the config param grouping_, but not when weighed against delaying the beta when it's this been long since a prior release. I perceive on balance what is in our users' best interests is having a release with all the defect fixes and features available in 4.0. This point of view stems from the empirical evidence of multiple users asking if the project is dead and expressing a strong interest in running 4.0 having heard of the proximity of the beta. I have no evidence of users stating that a lack of configuration grouping in the project causes them equal or greater pain, nor have I seen a cogent argument for that point of view. The underlying question we face is how we balance the value to end-users of having as optimal of an API as we can possibly come up in a specific domain vs. the value to end-users of the other things that are delayed due to that effort. Your point of view [~benedict] _appears to be_ that delaying the beta and the engagement of the user community's testing of the 4.0 release is justified by the value gained in grouping config params and not having a renamed paradigm for 4.0 and subsequent grouping paradigm in our next major. My apologies if I'm mis-characterizing your point of view here. It's within any committers prerogative to binding -1 things on justified technical grounds. I'd be curious what your perspective is on how we determine what qualifies as justified [~benedict], [~mck2] , and [~maedhroz] in a context such as this, as you all have expressed points of view here. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151336#comment-17151336 ] Benedict Elliott Smith commented on CASSANDRA-15234: > I am fairly opposed to shipping this in its current form and creating more > churn for operators when we change it again in the near future To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution for a public API. It is user unfriendly. I agree it is suboptimal to bring this to the ticket late in the game, but that is how the world sometimes works. This was not capricious or deliberate; nobody had thought of or suggested this until now, and everyone has since agreed this is a superior approach. If everyone changes their mind and agrees the current approach is the final and _superior_ solution, that is another matter. It would be a bit odd, however, implied positions so far. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151255#comment-17151255 ] Michael Semb Wever commented on CASSANDRA-15234: bq. I don't think this is an absolute necessity for pre-beta, however, given that we have agreed for it to be backwards compatible. I don't see any issue with landing this in a later beta. Move it out to a separate ticket, like was done for CASSANDRA-15876. To bring additional spec to the table, no matter how good it is, so late in the ticket and so close to the first beta, is particularly painful. As a separate ticket it can be done during the beta phase. Otherwise the settings now have a consistent naming pattern {{_}} which, no unit suffix noise, and better grouping the settings in the yaml, already brings a huge improvement. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150909#comment-17150909 ] Benedict Elliott Smith commented on CASSANDRA-15234: If we agree we will be changing the config parameters next version to this alternative approach, then I am fairly opposed to shipping this in its current form and creating more churn for operators when we change it again in the near future. The point of this exercise is to clean things up, not make them messier, and this includes the perspective of the end user and their ability to keep up with our nomenclature. I also think it would be a real shame not to include this work at all, given how awful and confusing our parameter naming situation is today. I don't think this is an absolute necessity for pre-beta, however, given that it is backwards compatible. I don't see any issue with landing this in a later beta. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150641#comment-17150641 ] Josh McKenzie commented on CASSANDRA-15234: --- {quote}Follow the suggestion for new parameters creation. Implement the suggested refactoring in the next major version. {quote} +1. This is one of 3 tickets left before beta and a new round of rework and validation this late in the alpha is inappropriate IMO. I'm sympathetic to the grouping; I find it superior aesthetically and more comprehensible, however balancing that against the need to get beta out and get people actively testing the DB leaves things in favor of the latter for me. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150619#comment-17150619 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thanks everyone for making a review/ providing a valuable input/advice. ?? Has this been considered? ?? No, it wasn't considered. I did the renaming as per {color:#0052cc}+the agreed plan+{color} . 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150579#comment-17150579 ] Caleb Rackliffe commented on CASSANDRA-15234: - {quote}but if we're doing this once, we should consider all the options {quote} We tend to follow the example of what has come before. (I fell into that trap initially trying to name a _new_ YAML option in CASSANDRA-15907.) If we can change it now, we can make that basic tendency work _for_ us. Agreed that it's a bit late in the process though. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150521#comment-17150521 ] Benedict Elliott Smith commented on CASSANDRA-15234: I haven't looked closely at this patch, but [~maedhroz] pointed out on another ticket that namespaces are a possibility, and this could dramatically simplify understanding the config file, and improve parameter naming as we try to shoe horn fewer things into a crazy long snake case name. Has this been considered? I don't want to muck things up this late in the game, but if we're doing this once, we should consider all the options - and I hope this change would be relatively minor compared to all the work [~e.dimitrova] has done (if we decide it makes sense, even, of course). > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150218#comment-17150218 ] Benjamin Lerer commented on CASSANDRA-15234: Some high leve comments: * I would prefer to avoid reading twice the configuration file if possible. It should be possible to replace {{YamlConfigurationLoader.readStorageConfig}} and {{isConfigFileValid}} by some checks in {{getProperty}} or by using the specific converters. As a side note: {{isConfigFileValid}} checks twice for the same condition on each of the {{if}} conditions. * The patch can be simplified by making {{Converter}} an {{enum}}. It will allow to use the enum value directly into the {{Replaces}} annotation. Doing so will remove the need to use reflection to instantiate the conveters and the use of a cache to avoid multiple instantiation. * The change in {{ConfigurationException}} are from some experimentations and should be removed. * I would as discussed previously defer the date of removal and remove {{scheduledRemoveBy}} from the {{Replaces}} annotation. * It would be nice to have more javadoc on the new code. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148858#comment-17148858 ] Benedict Elliott Smith commented on CASSANDRA-15234: bq. Given the framework makes it trivial to support old names, having no properties marked for removal of 5.0 works for me +1 > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148852#comment-17148852 ] David Capwell commented on CASSANDRA-15234: --- Given the framework provided by this patch, the following wouldn't be hard to support (all, not just 1 or 2) 1) no warning or plan to remove 2) warning that it will be removed some day 3) warning on specific version which will remove So, we could do the following {code} // provide a warning that this will not longer be supported after 5.0 @Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = Converter.MillisDurationConverter.class, scheduledRemoveBy = "5.0") public volatile Duration native_transport_idle_timeout = new Duration("0ms"); // provide a warning that the property is deprecated and will be removed one day @Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = Converter.MillisDurationConverter.class, deprecated = true) public volatile Duration native_transport_idle_timeout = new Duration("0ms"); // no warning, both properties are fully supported @Replaces(oldName = "native_transport_idle_timeout_in_ms", converter = Converter.MillisDurationConverter.class) public volatile Duration native_transport_idle_timeout = new Duration("0ms"); {code} Given the framework makes it trivial to support old names, having no properties marked for removal of 5.0 works for me. If we really want to migrate usage to a new name, then mark it to be removed one day, and stuff which is personal preference (such as enable at the start or end of the name) can have no warning; does this make sense? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148466#comment-17148466 ] Benjamin Lerer commented on CASSANDRA-15234: We could change the message to something like "will be removed in a futur major version". We can then decided later on when we wish to remove it. The JDK used some warning like that if I am not mistaken. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148460#comment-17148460 ] Michael Semb Wever commented on CASSANDRA-15234: bq. I think the same should be true of all of our public APIs: deprecate immediately, but only remove once the cost to maintain becomes unbearable. Is there a problem with advertising that the deprecation only lasts one major version, while we uphold that^ principle internally? i.e. we not making any commitment to the "scheduled to be removed by" statement, it's just a warning. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148441#comment-17148441 ] Benedict Elliott Smith commented on CASSANDRA-15234: My personal view is that for configuration parameters, so long as it is costless to maintain backwards compatibility we should do so. This includes parameters we remove between versions because we no longer use them (unless there is some semantic implication that the operator needs to consider). So, yes, indefinitely (but also with continued logging that the parameter is deprecated and might be removed). I think the same should be true of all of our public APIs: deprecate immediately, but only remove once the cost to maintain becomes unbearable. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148428#comment-17148428 ] Benjamin Lerer commented on CASSANDRA-15234: {quote}Do we need to remove the legacy parameters if they continue to mean the same thing? I think we should generally defer breaking deprecated public APIs until it's useful or necessary. We're doing this to cleanup for ourselves and for future users, not to make existing users have a bad time. {quote} [~benedict] Do you want to keep the backward compatibility forever or do you think that 5.0 is too soon to remove it? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147437#comment-17147437 ] Benedict Elliott Smith commented on CASSANDRA-15234: > it is scheduled to be removed by 5.0 Do we need to remove the legacy parameters if they continue to mean the same thing? I think we should generally defer breaking deprecated public APIs until it's useful or necessary. We're doing this to cleanup for ourselves and for future users, not to make existing users have a bad time. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17147386#comment-17147386 ] Michael Semb Wever commented on CASSANDRA-15234: I've added some (very minor) comments on the [commit|]https://github.com/ekaterinadimitrova2/cassandra/commit/f7ed1e00db5cc5810779a3d71dc065c750ba8e6b. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145765#comment-17145765 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thank you [~dcapwell]! Please find my comments below in Italic. I will also make a pass later again as I admit I was in a hurry to roll it out last night so it can be visible for people in more time zones before the end of the week to express any bigger concerns that I can address as this is a beta blocker. * Config. otc_coalescing_window_us_default was not renamed but the other otc* configs were. --> _will be corrected_ * block_for_peers_timeout_in_secs and block_for_peers_in_remote_dcs are exposed in yaml, the comment says "No need of unit conversion as this parameter is not exposed in the yaml file", can you explain why this comment? --> _it is not exposed in the yaml for the users so default value and unit is used as per the Config class setup_ * in database descriptor I see you use toString to compare, why not convert to the expected unit --> _I was testing and forgot to correct it, will make a pass to ensure it is corrected everywhere, thanks!_ * we should add docs for Replaces and ReplacesList (also calling out that you shouldn't use ReplacesList directly) --> _noted_ * for the new types, would be good to have a property test which validates that {code:java} type(value, unit).equals(type.parse(type(value, unit).toString())){code} --> _noted_ * LoadOldYAMLBackwardCompatibilityTest and ParseAndConvertUnitsTest look to be copy/paste. junit supports inheritance so could remove the copy based by having LoadOldYAMLBackwardCompatibilityTest extend ParseAndConvertUnitsTest but use the other config --> _will definitely take care of that, left over from the previous version, apologize_ > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17145118#comment-17145118 ] David Capwell commented on CASSANDRA-15234: --- This is a large patch, so will take a few attempts to review; below is my first pass (mostly skim). * Config. otc_coalescing_window_us_default was not renamed but the other otc* configs were. https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-new#diff-b66584c9ce7b64019b5db5a531deeda1R429 * block_for_peers_timeout_in_secs and block_for_peers_in_remote_dcs are exposed in yaml, the comment says "No need of unit conversion as this parameter is not exposed in the yaml file", can you explain why this comment? * https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-new#diff-76c34368f112a0a4e6da5b22c8b50300R353-R376. enums can use "abstract" methods, so you can do that rather than use a default which throws * in database descriptor I see you use toString to compare, why not convert to the expected unit? https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-new#diff-a8a9935b164cd23da473fd45784fd1ddR381. this could be {code}if (conf.commitlog_sync_period.toMillis() != 0){code}. This is true for all examples I see in this method * we should add docs for Replaces and ReplacesList (also calling out that you shouldn't use ReplacesList directly) * for the new types, would be good to have a property test which validates that {code}type(value, unit).equals(type.parse(type(value, unit).toString())){code}. * LoadOldYAMLBackwardCompatibilityTest and ParseAndConvertUnitsTest look to be copy/paste. junit supports inheritance so could remove the copy based by having LoadOldYAMLBackwardCompatibilityTest extend ParseAndConvertUnitsTest but use the other config. Overall I am good with this patch, need to do a closer review of the details still. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144711#comment-17144711 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - This patch implements the functionality which gives the end users the opportunity to attach units suffixes to DataStorage, Duration, BitRates parameters. It renames certain parameters with main goal - standardization. Backward compatibility implemented on parameter level utilizing annotations. [Branch |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new] This patch requires custom [ [DTests |https://github.com/ekaterinadimitrova2/cassandra-dtest]] which run successfully with the following patch of [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new] (The failed test in circle are failing because the CCM patch didn't apply due to config issue. Also, one exclusion of warning about using the old parameters names should be added. Upgrade tests still running) DTests - requirements.txt should be updated back to the original one before commit! [ [JAVA8 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/98c356fb-b16a-4508-bda8-ff877569b0f5]] [ [JAVA11 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/257/workflows/d49295a8-d8f5-4836-a18a-df25ff955219]] *TO DO:* IN-JVM tests are not using snakeyaml so I have to update them to use its converter in order for the tests to work with this patch. This is feasible solution aligned with Alex Petrov and [~dcapwell]. I will provide the additional patch/commit until the end of the week but didn't want to delay the review of the main patch further. *WARNING:* Before commit return to the default requirements.txt file *Order of commits:* 1) [ [CASSANDRA branch |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-new]] 2) [ [CCM branch |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-new]] 3) [ [DTests branch |https://github.com/ekaterinadimitrova2/cassandra-dtest]] > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17138929#comment-17138929 ] David Capwell commented on CASSANDRA-15234: --- This isn’t a review and I’m aware I said I didn’t have time to review it a month ago, but I glanced at the patch and it seems quite different from the approach discussed in https://the-asf.slack.com/archives/DSP76MVPC/p1589983705004900 and https://the-asf.slack.com/archives/DSP76MVPC/p1590006263021200. Can you say a bit about why you changed your approach? > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136171#comment-17136171 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thank you [~mck] I agree with you, CASSANDRA-15876 was created to facilitate this work. It is also not a 4.0 Beta blocker(I set the fix version to beta there) and I think we might be even able to further develop it. Let's continue the discussion there. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136129#comment-17136129 ] Michael Semb Wever commented on CASSANDRA-15234: [~e.dimitrova], can we pull out the part 3 (Accessors for System properties) patch into a separate ticket. If it has no dependencies on the other patches in this ticket, then there's no reason it can't get reviewed and committed separately. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127857#comment-17127857 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - Thanks to a recent patch I managed to run the upgrade tests in CircleCI. The [results |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/207/workflows/1d0a0a87-16d9-467b-9299-bb148cb10f68/jobs/1223] look good(more than 700 failures but they are those which are currently presented on trunk in CircleCI and mostly related to the environment) when we use the old current DTest suite, CCM and cassandra.yaml. Using the old cassandra.yaml is actually the way a real upgrade will happen. In order to run the upgrade tests using the newly proposed version of the DTests suite and CCM, I need to take care about a couple of places where the suite checks for Cassandra version and tries respectively to load some of the parameters with their new names which causes cluster start issues, preventing some of the upgrade tests from run. Currently identified the primary conflict to be in dtest_setup.py. After that scripts is adjusted there are only around 20 tests which fail [here |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/206/workflows/1f7b0a54-c9e2-4305-8c94-be08d07846dd/jobs/1217/tests]. One of the other issues is the new name _materialized_views_enabled due_ {color:#172b4d}to which some of the cql tests fail.{color} Quick intermediate solution to the mentioned problems would be to add a script which: 1) runs before the upgrade tests start 2) replaces the new cassandra.yaml file with the old one 3) sets the names of the parameters which would cause issues to their old names which as far as I see are 6-7 compared to almost 70 changed names according to this patch. Then I can open a follow-up ticket for fix of the tests so we don't use this customization in the long term but I find this current issue as not being a blocker for the patch or Beta. *TO DO:* Update the Upgrade documentation with the steps of upgrading to version 4 with the old cassandra.yaml and then updating the cassandra.yaml. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17127003#comment-17127003 ] Michael Semb Wever commented on CASSANDRA-15234: Thanks for the summary post [~e.dimitrova]. For the first [part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-3-rebase] (including the dtest and ccm changes), the ASF CI pipeline results are [here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/144/]. In addition the ASF CI dtest upgrade test results are [here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/9/]. For the second [part|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-5] the ASF CI results are [here|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/145/pipeline]. > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126974#comment-17126974 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - *Summary:* This branch contains: - [first commit | https://github.com/ekaterinadimitrova2/cassandra/commit/a8a9145a032a9f2d9b74369f2e4474a210aa5b99] which contains parameters name changes as requested; backward compatibility with the old names; Proposed new structure into [sections |https://issues.apache.org/jira/browse/CASSANDRA-15234?focusedCommentId=17057969=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17057969] for cassandra.yaml. - the [second commit | https://github.com/ekaterinadimitrova2/cassandra/commit/032fbd8cca1d7b5b96738bd96d9672864426d718] implements the functionality which gives the end users the opportunity to attach units suffixes to Memory, Duration, Rates parameters. - [third commit |https://github.com/ekaterinadimitrova2/cassandra/commit/68f89503e6e6f30e8f6df1374cb553f243f0068e] is a ninja fix of one line which was changed in a wrong way during the latest rebase. - [fourth commit |https://github.com/ekaterinadimitrova2/cassandra/commit/8389010d704a9524a1c36d96f9e4d8179a8e2044] is to return the default config.yml This patch requires custom [ [DTests | https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] ] which run successfully with the following patch of [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] DTests - requirements.txt should be updated back to the original one before commit! The tests are not backward compatible with the yaml file without units suffixes. This part is covered by a unit test which tests the successful load of the values of the parameters without units as per the old format. [ [trunk |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-3-rebase ] ] [ [DTests | https://github.com/ekaterinadimitrova2/cassandra-dtest/tree/CASSANDRA-15234-3] ] [ [CCM |https://github.com/ekaterinadimitrova2/ccm/tree/CASSANDRA-15234-3] ] [ [JAVA8 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/718c8a04-385b-4ddc-ac2e-9291c37b1f1e] ] [ [JAVA11 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/193/workflows/6cd6048d-5daf-4490-a5d3-b5c3178a0757 ] ] Attached to the ticket is the log of the successful runs of the few failing JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as it didn't make sense to me to rerun the whole suite of tests. *Last update:* after rebase and a few nits on my end, we have only 1 DTest and 1 Unit test failing in JAVA11. Unrelated known failures. CQLSH JAVA11 tests are not currently available in CircleCI. This branch is a class of Accessors System properties. *This patch could be considered separate of the previous one.* It doesn't require custom DTests or custom CCM. [ [trunk |https://github.com/ekaterinadimitrova2/cassandra/tree/CASSANDRA-15234-5] ] [ [JAVA8 CI |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/ebd771ac-d71c-49ea-872b-00b534d9d5c6] ] [ [JAVA11 CI |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/195/workflows/19a3254b-cd7a-4e4f-856f-f314546ff9d7] ] There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check for tickets logged. *WARNING:* Before commit return to the default requirements.txt file > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126815#comment-17126815 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - This one is ready for final review I think. [~mck] I am not a committer but I think it would be great also to run the tests in Jenkins. Thank you > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126344#comment-17126344 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - [ trunk ] [ DTests ] [ CCM ] [ JAVA8 ] [ JAVA11 ] Attached to the ticket is the log of the successful runs of the few failing JAVA8 DTests in CircleCI. I ran them locally after fixing lost line of code as it didn't make sense to me to rerun the whole suite of tests. Last update: after rebase and a few nits on my end, we have only 1 DTest and 1 Unit test failing in JAVA11. Unrelated known failures. added additional note on the possible units to be used as suffixes in both NEWS.txt and cassandra.yaml CQLSH JAVA11 tests are not currently available in CircleCI. The last part is all green after rebase and CI run. "line.separator" getter added [ [trunk|] ] [ JAVA8 CI ] [ JAVA11 CI ] There are 1 DTest and 1 Unit unrelated failing tests in JAVA11. Should check for tickets logged. *NOTE: *Before commit return to the default config.yml and requirements.txt files > 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 > > > 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
[jira] [Commented] (CASSANDRA-15234) Standardise config and JVM parameters
[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126135#comment-17126135 ] Ekaterina Dimitrova commented on CASSANDRA-15234: - *UPDATE:* - the unit test is a flakey test. The configuration is properly loaded so it is not caused by this patch. - small issue with Auth_test.py was fixed. - the rest of the failing unit tests are related to current failures we already see on trunk. Some of them are already fixed in the newer commits. Rebase and run new CI now to confirm the latest status. > 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 > > > 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