[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066238#comment-17066238
]
Ekaterina Dimitrova edited comment on CASSANDRA-15234 at 3/24/20, 10:27 PM:
----------------------------------------------------------------------------
Hi [~dcapwell]
Thanks a lot for your feedback!
"_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)._"
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.
"_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?)_"
I was thinking about this, too. But in this case we don't change only one or
two parameters but 15 for now. And when I also add the change of those which
had a unit at the back... they will be a lot. Also, my point was that we change
completely the version of the yaml. Did you check it how it looks like now?
So from now on any changes/comments/recommendations will go there. We don't
want people to start making changes on the old yaml but potentially to update
it with the new one.
"_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.
Yes, that was exactly my point. Also, we can easily get rid of this backward
compatibility one day in the future if we want to._
_My main question is how this works with a nested property? Lets say we want
to change the yaml to
seed_provider:_
_# renamed class_name to name
- name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "127.0.0.1:7000"_
_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)._"
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.
"_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_"
Same here, thanks.
was (Author: e.dimitrova):
Hi [~dcapwell]
Thanks a lot for your feedback!
"_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)._"
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.
"_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?)_"
I was thinking about this, too. But in this case we don't change only one or
two parameters but 15 for now. And when I also add the change of those which
had a unit at the back... they will be a lot. Also, my point was that we change
completely the version of the yaml. Did you check it how it looks like now?
So from now on any changes/comments/recommendations will go there. We don't
want people to start making changes on the old yaml but potentially to update
it with the new one.
"_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.
Yes, that was exactly my point. Also, we can easily get rid of this backward
compatibility one day in the future if we want to.
My main question is how this works with a nested property? Lets say we want
to change the yaml to
seed_provider:
# renamed class_name to name
- name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "127.0.0.1:7000"
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)._"
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.
"_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_"
Same here, thanks.
> 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
