[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065977#comment-17065977
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-2#diff-b66584c9ce7b64019b5db5a531deeda1R189
I prefer native_transport_max_threads over max_native_transport_threads, the
native_transport prefix scopes things better IMO and matches the other configs
as well (such as native_transport_flush_in_batches_legacy).
https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-2#diff-5749c5e00813f3ae16b68ff8de095cc0R238
I feel it makes sense to put that in the if block
https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-2#diff-5749c5e00813f3ae16b68ff8de095cc0R227
and remove isOldYAML
https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-2#diff-5749c5e00813f3ae16b68ff8de095cc0R305
log isn't actionable, personally feel logging which properties were used but
deprecated is easier to act on (so may be better to log per property?)
For the parsing remapping logic, I am good with this, it keeps Config.java
clean and removes the need for DatabaseDescriptor to do the remapping. My main
question is how this works with a nested property? Lets say we want to change
the yaml to
{code}
seed_provider:
# renamed class_name to name
- name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "127.0.0.1:7000"
{code}
Not sure if we care about something like that now, but its the main question I
have on the remapping (and potential conflict where top level != nested).
bq. For example, still wondering a bit about the best place to incorporate the
parsing(also the unit converts...) to ensure least disruptions in the current
code logic. Looks to me that it might be good again to call it during the yaml
file load.
I personally prefer the parsing in the file loading since it can give more
meaningful feedback to users than failing somewhere else. Also would mean that
Config.java always has the final results
> 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
