[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17057969#comment-17057969
]
Ekaterina Dimitrova commented on CASSANDRA-15234:
-------------------------------------------------
Ok, back to this one. Unfortunately, I was parallelizing with some other stuff
at the beginning of the week.
Thanks [~mck] for sharing that ticket, that was helpful.
I started from looking into standardizing the parameters names and 1) of the
plan [~dcapwell] shared.
Also, my idea was to reshuffle a bit the order of the parameters in the yaml
and try to put them in sections, for example:
* Quick start
The minimal properties needed for configuring a cluster.
* Commonly used
Properties most frequently used when configuring Cassandra.
* Performance Tuning
Tuning performance and system resource utilization, including commit log,
compaction, memory, disk I/O, CPU, reads, and writes.
* Advanced
Properties for advanced users or properties that are less commonly used.
* SecurityServer and client security settings.
Yes, this idea came after looking at online documentations and trying to think
from user's perspective.
On another topic, looking at the plan, I realized that you might want actually
a parser and unit converter for the values in order to give freedom to the
users to add whatever value they would like in the yaml. Initially, I was
thinking that we talk about the suffixes of the parameters names, the way we
see them now and some name changes and backward compatibilities.
So my question is what is the reason behind doing this and shall we split this
Jira then in a couple of smaller ones if we go into that direction?
> 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, 4.0-beta
>
>
> 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
