With the flat structure it turns into properties file - would it be possible to support both formats - nested yaml and flat properties?
- - -- --- ----- -------- ------------- Jacek Lewandowski On Fri, Nov 19, 2021 at 10: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 > > > > >
