[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480375#comment-17480375
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/22/22, 9:19 AM:
------------------------------------------------------------------------------
bq. To me grouping based off feature is the only way for a config to actually
be "discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind.
In my experience this is a near-impossible task to do consistently with an
intuitive structure, as nobody really agrees what features should be called,
let alone their hierarchy.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
caches? Logically it _could_ include half of the settings.
Many things also don't neatly fall under any feature, so we will fabricate
features for them: non-query timeouts cannot be grouped under {{query}}, so now
we probably _won't_ group query timeouts under {{query}} either, else it will
be inconsistent. But now both are inconsistent, there's no rules underpinning
it anymore.
This kind of grouping can also be more volatile - once a new setting (and
suitable grouping) is introduced, it more readily affects the decisions for the
existing hierarchy. This means this kind of layout probably needs a lot of
upfront work to produce a coherent grouping for the whole config file, to
demonstrate that it can be done in a manner everyone agrees on, and to avoid
lots of churn.
I think when I tried to produce groupings, your approach was what I tried
initially before deciding this approach was cleaner. Plus it has the added
benefit that a user that _doesn't_ know the config options (i.e. most users),
when encountering instability, will have good discoverability of dials that can
be modified to improve cluster health. I think this is a very underrated
benefit, as most users cannot afford teams of developers that are intimately
familiar with the codebase.
was (Author: benedict):
bq. To me grouping based off feature is the only way for a config to actually
be "discoverable", pulling bits and pieces out to other places because they are
"limits" would always break this in my mind.
In my experience this is not only a near-impossible task, but leads to
inconsistency (in both leaf-node naming and in grouping) and a non-intuitive
structure, as nobody really agrees what any features should be called, and
certainly not what they should be grouped under. Names and groupings are
entirely arbitrary, and something that is natural to some will be unnatural to
another.
For instance, once you have a {{query}} heading, should that then include
coordinator level configurations? timeouts? concurrency? CQL configurations?
Logically it could include half of the settings. So it becomes arbitrary, and
importantly much more volatile - once a new setting and suitable grouping is
introduced for a new property, either the consistency is harmed or settings
need to be moved to another group, much like they would with an internal API.
It would also likely need to be a much bigger bang piece of work, and would
likely necessitate much more disparate documentation, as the _effect_ of each
setting likely needs to be described repetitiously. At the very least, anybody
who wants this kind of layout needs to try producing such a coherent grouping
for the whole config file, to demonstrate that it can be done, and to avoid
lots of churn.
TL;DR: it's messy, arbitrary and inconsistent. But if that's what everyone
wants, some work needs to be done upfront to prove it can be done cleanly IMO.
> Migrate threshold for minimum keyspace replication factor to guardrails
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-17212
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17212
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
> Reporter: Andres de la Peña
> Priority: Normal
>
> The config property
> [{{minimum_keyspace_rf}}|https://github.com/apache/cassandra/blob/5fdadb25f95099b8945d9d9ee11d3e380d3867f4/conf/cassandra.yaml]
> that was added by CASSANDRA-14557 can be migrated to guardrails, for example:
> {code}
> guardrails:
> ...
> replication_factor:
> warn_threshold: 2
> abort_threshold: 3
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
