[
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, 8:51 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 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.
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 an impossible task, but leads to
inconsistency 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
