[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160264#comment-17160264
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
Thanks [~maedhroz] and [~benedict] for the YAML examples; it would be great to
start this dialog on user@ to get peoples feedback.
bq. I personally would like to propose we also introduce a dual system for
updating properties, wherein we can accept the nested namespace versions, as
well as e.g. dot-delimited versions. e.g. disk.throttle.compaction: 10MiB/s.
This should mitigate any risk to simplistic tools, as well as maybe providing
us a simple route to permitting common options being given at the start of the
file, without confusing the overall approach.
So the following would be supported?
{code}
compaction_throughput_mb_per_sec: 42
disk:
throttle:
compaction: 42MiB/s
disk.throttle.compaction: 42MiB/s
{code}
I assume the semantics would require mixed to work (part of the disk.throttle
is nested, other parts are not) and wouldn't allow duplication definitions with
other versions (can only use 1 of the 3 forms, not all), so doesn't seem that
bad as that logic already exists. We walk the class to discover the previous
names, so can do the same or collect the shape while we walk.
My main concern is if this makes it more confusing for users; they may find
some docs which say the old name, some using the nested name, and others using
the flat name.
> 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
