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