> 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
