[ 
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17470013#comment-17470013
 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 1/6/22, 4:16 PM:
--------------------------------------------------------------------------

Thank you [~maedhroz] . I already addressed the first two commits review 
comments, 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}{quote} 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}{quote}
In theory we have backward compatibility with the old yaml&config, 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. 


was (Author: e.dimitrova):
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&config, 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

Reply via email to