It only works if the output is for human to read. If you have a large
number of servers, very often you want to do "grep -q ... &&
other_command" (or || other_command), or chaining the grep results frin
parallel-ssh into another command (grep or sort). The -A/-B/-C switches
will not work in this case. If the nested configurations have multiple
keys with the same name (e.g.: a dictionary where the values are very
similar dictionaries), even chaining 3 grep commands in the form of
"grep -A ... | grep -B ... | grep -q ... " is unlikely to work.
Structured / nested config is easier for human eyes to read but very
hard for simple scripts to handle. Flat config is harder for human eyes
but easy for simple scripts. I can see user may prefer one over another
depending on their own use case. If the structured / nested config must
be introduced, I would like to see both syntaxes supported to allow the
user to make their own choice.
On 24/11/2021 16:21, Henrik Ingo wrote:
Grepping is an important use case, and having worked with another database
that does nest its configs, I can offer some tips how I survived:
With good old grep, it can help to use the before and after options:
grep -A 5 track_warnings | grep -B 5 warn_threshold
Would find you this:
track_warnings:
enabled: true
coordinator_read_size:
warn_threshold: 10kb
It would require magic expert knowledge to guess right numbers for -A and
-B but in many cases you could just use a large number like 9999 and it
will work in most cases.
For more frequent use, you will want to just install `yq` (aka yaml query):
https://github.com/kislyuk/yq
henrik
On Fri, Nov 19, 2021 at 9:07 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
