> it is really handy to grep
> cassandra.yaml on some config key and you know the value instantly.
You can still do that
$ grep -A2 coordinator_read_size conf/cassandra.yaml
# coordinator_read_size:
# warn_threshold_kb: 0
# abort_threshold_kb: 0
I was also arguing we should support nested and flat, so if your infra works
better with flat then you could use
track_warnings.coordinator_read_size.warn_threshold_kb: 0
track_warnings.coordinator_read_size.abort_threshold_kb: 0
> On Nov 19, 2021, at 1:34 PM, David Capwell <dcapw...@apple.com> wrote:
>
>> With the flat structure it turns into properties file - would it be
>> possible to support both formats - nested yaml and flat properties?
>
>
> For majority of our configs yes, but there are a subset where flat properties
> is annoying
>
> hinted_handoff_disabled_datacenters - set type, so you could do
> hinted_handoff_disabled_datacenters=“a,b,c,d” but we would need to deal with
> separators as the format doesn’t support
> seed_provider.parameters - this is a map type… so would need to do something
> like seed_provider.parameters=“{\”a\”: \a\”}” …. Maybe we special case maps
> as dynamic fields? Then seed_provider.parameters.a=a? We have
> ParameterizedClass all over the code
>
> So, as long as we define how to deal with java collections; we could in
> theory support properties files (not arguing for that in this thread) as well
> as system properties.
>
>
>> On Nov 19, 2021, at 1:22 PM, Jacek Lewandowski <lewandowski.ja...@gmail.com>
>> wrote:
>>
>> 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
>>>>
>>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
