[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451448#comment-17451448
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
bq. DTests were not updated to the new names and format as this will take
forever. Suggestion - leave the old ones and add new tests with new ones. We
can also open a follow up ticket but now this exercises the backward
compatibility which is good as this is also how I figured out one more change
needed for CCM.
works for me; more testing we didn't break things ^_^
bq. I suggest not to overwhelm the patch with the reorganization of
cassandra.yaml I suggested earlier on this ticket. I will pull it in a separate
one and I can trigger a new discuss thread on the mailing list to confirm that.
Works for me
bq. Converter was not changed to an enum because we need generics support for
that and JEP301 was withdrawn.
Works for me
bq. Intentionally left the commits after the old patch not squashed to provide
some input and hopefully make the review a bit more easy. Benjamin Lerer and
David Capwell , please, let me know if you want them in a different way for the
review.
Personally prefer PRs, easier to leave comments than commits
bq. Any new parameters added post 4.0 in trunk were/will be directly changed to
support the new format as they are still not in any release.
Saw the TrackWarning changes.... <3
bq. I can think of adding some additional test for the virtual table.
I am 100% cool leaving the vtable problem to another ticket =). Right now it
will show the new names, if we want different behavior we can solve it outside
of this JIRA. We are having side conversations on how can we unify (at least I
am pushing this) properties access.
bq. I also suggest we add a warning to the users when they start Cassandra that
if they add more than once a property (even if it is the old name), the latest
occurrence from the yaml file will be the one assigned to the parameter. I
would say we add also info to the docs and we don't complicate to add checks
whether we have or not more occurrences during startup and emitting warnings on
occurrence as it seems a bit too much overhead on startup. WDYT?
Ideally I like this, but also 100% cool not doing in this patch.
{code}
a: b
a: c
{code}
that has worked for years without anyone noticing... if adding a warning is
low-hanging-fruit then I am cool, but I wouldn't hold up this ticket (I like
splitting tickets if you have not noticed).
> 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: 5.x
>
> 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
