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

Ryan Svihla commented on CASSANDRA-15234:
-----------------------------------------

I think this is overall a good idea, but it definitely needs some limits on the 
number of combinations supported. Let's just look at a hypothetical new 
configuration `compaction_throughput` instead of 
`compaction_throughput_mb_per_sec` (which is a poster child for a difficult to 
remember name in need of review):

* Any downstream tooling that reads configuration will have to take on 
everything we add, which is fine, but the more math we require the worse it is 
on them to get updated. An older tool will read 
compaction_throughput_mb_per_sec and it was self documenting. A new tool will 
have to take into account every variant we support for MiB/MB/mb/bytes/etc/etc
* what about `500mb` vs `500mb/s` vs `500 mbs` (note the space) vs `500MiB/s` 
vs `500  mb/s` (note the 2 spaces). Which of those is obviously valid or wrong 
at a glance to a new user? So if we're going to do it, definitely only accept 
one valid that's the same for everything..I still think it's adding some 
learning curve for new users.

> 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

Reply via email to