[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066284#comment-17066284
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 3/25/20, 12:32 AM:
----------------------------------------------------------------------------
I mentioned in the initial submission... I propose the new version. Cassandra
should come only with one version, the new one.
But the old one was kept for now for the backward compatibilities CI run and
verification.
The idea is to have the new one v2.
The old one won't be there anymore. I can leave it only in test/conf for test
purposes.
So that's why I didn't consider just to list all the parameters and say rename
so they rename them in the old version.
v2 logic I mentioned before that I am gonna add it and no one objected.
This is initial version to get some feedback while completing the rest of the
stuff. Thank you for providing it.
was (Author: e.dimitrova):
I mentioned in the initial submission... I propose the new version. Cassandra
should come only with one version, the new one.
But the old one was kept for now for the backward compatibilities CI run and
verification.
The idea is to have the new one v2.
The old one won't be there anymore. I can leave it only in test/conf for test
purposes.
So that's why I didn't consider just to list all the parameters and say rename
so they rename them in the old version.
v2 logic I mentioned before that I am gonna add it and no one objected.
> 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
