[ https://issues.apache.org/jira/browse/CASSANDRA-15234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17058024#comment-17058024 ]
Benedict Elliott Smith edited comment on CASSANDRA-15234 at 3/12/20, 3:39 PM: ------------------------------------------------------------------------------ My personal view is that there's no need to overcomplicate this ticket, and that perhaps David Capwell anticipates greater complexity in addressing it than I do. My goal is to make the config more intuitive, consistent and also to not make any assumptions about reasonable units. Every property has its own units picked arbitrarily, and this is confusing. Publishing a simple regex to validate the value types for tools seems sufficient to address [~rssvihla]'s concerns, I think? And I don't think we should make it pluggable, just accept quantities and rates, and we can be quite restrictive, even just accepting GiB/s, MiB/s and KiB/s. My personal approach would be to, in separate commits but one ticket # Move properties to a single file, with strongly typed methods and sensible names for fetching the property. # Note property names present in either {{Config}} or via system properties, that relate to the same concept but use different terms - not just prefixes like otc_, but also: #* Why do we use {{enable}}, {{enabled}} and {{disable}} in our property names? Why does it sometimes go at the start or end? #* Why do we use both {{dc}} and {{datacenter}}? #* Who does {{max}} sometimes go at the start, sometimes in the middle? #* ... # Rename things, and make sure {{Config}} and system properties look for both old and new forms # Support super simple parsing for rate and size # Done was (Author: benedict): My personal view is that there's no need to overcomplicate this ticket, and that perhaps David Capwell anticipates greater complexity in addressing it than I do. My goal is to make the config more intuitive, consistent and also to not make any assumptions about reasonable units. Every property has its own units picked arbitrarily, and this is confusing. Publishing a simple regex to validate the value types for tools seems sufficient to address [~rssvihla]'s concerns, I think? And I don't think we should make it pluggable, just accept quantities and rates, and we can be quite restrictive, even just accepting GiB/s, MiB/s and KiB/s. My personal approach would be to, in separate commits but one ticket # Move properties to a single file, with strongly typed methods and sensible names for fetching the property. # Note property names present in either {{Config}} or via system properties, that relate to the same concept but use different terms - not just prefixes like otc_, but also: #* Why do we use {{enable}}, {{enabled}} and {{disable}} in our property names? Why does it sometimes go at the start or end? #* Why do we use both {{dc}} and {{datacenter}}? #* Who does {{max}} sometimes go at the start, sometimes in the middle? #* ... # Rename things, and make sure {{Config}} and system properties look for both old and new forms # Done > 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