[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
