[
https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152266#comment-17152266
]
David Capwell commented on CASSANDRA-15234:
-------------------------------------------
Reread the conversations that have been going on over the past 3 days several
times, sorry if I missed anything or didn't grasp all points.
Most of the thread is about doing an all or nothing approach, thanks [~mck] for
trying to argue for incremental improvement. Looking at the list of properties
impacted (see
https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:CASSANDRA-15234-new#diff-4302f2407249672d7845cd58027ff6e9R257-R339)
it looks like a subset would be clearly impacted by the grouping approach, and
others not so much or are complementary; given this we could accept a hand full
of the properties and move the other properties into the grouping work (stuff
such as read_request_timeout_in_ms to read_request_timeout I feel are fine even
with the grouping approach, but stuff which renames things maybe leave out for
now, such as enable_user_defined_functions to user_defined_functions_enabled).
I do agree with [~benedict] that it isn't ok to keep changing our config API
since this is user facing, we should be strict about user facing changes and
try to help more than harm. If there is a belief that one structure is better
than another then I value this dialog and hope we can get more eyes from the
users/operators to see their thoughts; for this work we should really speak
about the YAML representation rather than the code so we can agree on the final
result. Also, given the framework that is provided by this patch, I don't see
that work as throwing everything away, instead I see it benefiting from the
work which is started. Given the work involved is to add support for "moving"
a field (current "rename" is a special case of move where the move is at the
same level) from one location to another (rename and conversion already
supported), this adds complexity for the case where the new and the old field
are both used and may hit complexity issues with SnakeYaml implementation. I
do believe we should have this discussion and settle on a solution before
releasing 4.0.0, but I do not feel that this discussion blocks a beta release.
There is a lot of chatting about being a beta blocker but I don't really follow
why this JIRA (or the grouping one) is a blocker. Reading
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle I don't
see why this JIRA could not be done during beta, it meets every requirement for
this phase.
Given all the comments above, my TL;DR
* Can we find a subset of properties with the current patch which are not
discarded by the grouping work (sample given above)
* Can we start the conversation and start asking operators of Cassandra
clusters on their thoughts on grouping vs not grouping? Grouping could be nice
for humans but could be horrid for some automation (I am neither pro or against
grouping, I defer to operators preference here).
* Can we mark this ticket and the grouping one as non-blocking for beta
> 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: [email protected]
For additional commands, e-mail: [email protected]
