[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17151336#comment-17151336
]
Benedict Elliott Smith edited comment on CASSANDRA-15234 at 7/4/20, 1:56 PM:
-----------------------------------------------------------------------------
> I am fairly opposed to shipping this in its current form and creating more
> churn for operators when we change it again in the near future
To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution
for a public API. It is user unfriendly.
I agree it is suboptimal to bring this to the ticket late in the game, but that
is how the world sometimes works. This was not capricious or deliberate;
nobody had thought of or suggested this until now, and everyone has since
agreed (or implied) this is a superior approach.
If we change our minds and agree the current approach is the final and superior
solution, that is another matter.
The approaching release of 4.0 should not reduce our attention to detail or
quality. We should merge tickets only when we agree they are ready. This is
particularly important for tickets whose main impact is improving a public API.
was (Author: benedict):
> I am fairly opposed to shipping this in its current form and creating more
> churn for operators when we change it again in the near future
To be more explicit: I am (binding) -1 knowingly shipping an _interim_ solution
for a public API. It is user unfriendly.
I agree it is suboptimal to bring this to the ticket late in the game, but that
is how the world sometimes works. This was not capricious or deliberate;
nobody had thought of or suggested this until now, and everyone has since
agreed this is a superior approach.
If everyone changes their mind and agrees the current approach is the final and
_superior_ solution, that is another matter. It would be a bit odd, however,
given implied positions so far.
The approaching release of 4.0 should not reduce our attention to detail or
quality. We should merge tickets only when we agree they are ready.
> 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-alpha
>
> 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
