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