Hi David, while I do not oppose nested structure, it is really handy to grep cassandra.yaml on some config key and you know the value instantly. This is not possible when it is nested (easily & fastly) as it is on two lines. Or maybe my grepping is just not advanced enough to cover this case? If it is flat, I can just grep "track_warnings" and I have them all.
Can you elaborate on your last bullet point? Parsing layer ... What do you mean specifically? Thanks On Fri, 19 Nov 2021 at 19:36, David Capwell <dcapw...@gmail.com> wrote: > > This has been brought up in a few tickets, so pushing to the dev list. > > CASSANDRA-15234 - Standardise config and JVM parameters > CASSANDRA-16896 - hard/soft limits for queries > CASSANDRA-17147 - Guardrails prototype > > In short, do we as a project wish to move "new features" into nested > YAML when the feature has "enough" to justify the nesting? I would > really like to focus this discussion on new features rather than > retroactively grouping (leaving that to CASSANDRA-15234), as there is > already a place to talk about that. > > To get things started, let's start with the track-warning feature > (hard/soft limits for queries), currently the configs look as follows > (assuming 15234) > > track_warnings: > enabled: true > coordinator_read_size: > warn_threshold: 10kb > abort_threshold: 1mb > local_read_size: > warn_threshold: 10kb > abort_threshold: 1mb > row_index_size: > warn_threshold: 100mb > abort_threshold: 1gb > > or should this be "flat" > > track_warnings_enabled: true > track_warnings_coordinator_read_size_warn_threshold: 10kb > track_warnings_coordinator_read_size_abort_threshold: 1mb > track_warnings_local_read_size_warn_threshold: 10kb > track_warnings_local_read_size_abort_threshold: 1mb > track_warnings_row_index_size_warn_threshold: 100mb > track_warnings_row_index_size_abort_threshold: 1gb > > For me I prefer nested for a few reasons > * easier to enforce consistency as the configs can use shared types; > in the track warnings patch I had mismatches cross configs (warn vs > warns, fail vs abort, etc.) before going nested, now everything reuses > the same types > * even though it is longer, things can be more clear how they are related > * parsing layer can add support for mixed or purely flat depending on > user preference (example: > track_warnings.row_index_size.abort_threshold, using the '.' notation > to represent nested structures) > > Thoughts? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
