I'm on record as early as the comments in CASSANDRA-15234 in support of nesting, and I think the biggest reason is that the structure it forces on our config makes it more cohesive and intelligible to those trying to understand how major features and subsystems work together. It's very easy to look at our current flat configuration and miss an option that modifies or in some way governs another.
On the subject of mass-grepping via ssh, I would be careful. We have a large and growing set of hot-properties, and looking at the YAML files might not actually reflect how those nodes are currently configured. On Fri, Nov 19, 2021 at 3:08 PM Caleb Rackliffe <calebrackli...@gmail.com> wrote: > If it's nested, "track_warnings" would still work if you're grepping > around vim or less. > > I'd have to concede the point about grep output, although there are tools > like https://github.com/kislyuk/yq that could probably be bent to do what > you want. > > On Fri, Nov 19, 2021 at 1:08 PM Stefan Miklosovic < > stefan.mikloso...@instaclustr.com> wrote: > >> 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 >> >>
