[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org