[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066269#comment-17066269
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
bq. I agree with this. On the other hand, we keep all max/min/etc at the
end/start of a name, that was the initial plan I think.
naming is hard, ill defer to others who have stronger opinions
bq. they will be a lot.
yep, which is why it would be good to tell the users which ones are deprecated
and replaced with what. If we just say "there is a problem" they will find out
what the problem was in 5.0 (and only then try to figure out how to migrate).
bq. Also, my point was that we change completely the version of the yaml.
I saw you have v2 logic, but don't understand why given the current patch; is
there more pending which change the structure?
bq. Did you check it how it looks like now?
Do you mean the YAML? the log looks the
[same|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-2#diff-5749c5e00813f3ae16b68ff8de095cc0R305]
to me. I see you have the two yaml; not sure about others but IMO we should
only have 1 file (since users see it), two could be confusing.
bq. We don't have that issue now but it looks like snakeyaml has everything in
place in order to deal with nested parameters, too. Not sure I responded to
your question.
the current patch doesn't have the need, was just thinking about if it came up
and the impact to the rename logic; the patch currently makes sense for top
level names.
> 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
