[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478015#comment-17478015
]
Benedict Elliott Smith edited comment on CASSANDRA-17212 at 1/18/22, 4:26 PM:
------------------------------------------------------------------------------
The problem with your proposed layout is that you seem to fan out on the
involved part of Cassandra rather than the category of effect, so that at the
very least there is high fan out - but, also for consistency you would
naturally expect concurrency limits to be nested under read, write, etc,
leading to a config that look like this:
{code}
limits:
read:
concurrency: 32
write:
concurrency:32
{code}
I think consistency is important in a config file, as is maximally grouping
concepts. But also we want the config file to be naturally discoverable, and
self-documenting. For instance, I may know I have a warning I want to modify,
but do I know in advance if it is called {{corrupt_value_size}}? Probably not.
So I can find it more easily by the alternative approach. Similarly,
documentation can span an entire category of limit, with hopefully most
terminal parameter names being adequately descriptive of the part of system we
are addressing, to obviate further documentation (or else, it can be renamed,
or a minimal single line may suffice)
I'm not entirely sold on the idea of globally enabling/disabling limits either,
but perhaps it might make sense to permit switching on/off categories of limit
(warn, error, info etc)?
was (Author: benedict):
The problem with your proposed layout is that you seem to fan out on the
affected system rather than the systemic effect, so that at the very least
there is high fan out, but also for consistency you would expect concurrency
limits to be nested under read, write, etc, leading to a config that look like
this:
{code}
limits:
read:
concurrency: 32
write:
concurrency:32
{code}
I think consistency is important in a config file, as is maximally grouping
concepts. But also we want the config file to be naturally discoverable, and
self-documenting. For instance, I may know I have a warning I want to modify,
but do I know in advance if it is called {{corrupt_value_size}}? Probably not.
So I can find it more easily by the alternative approach. Similarly,
documentation can span an entire systemic impact, with hopefully most terminal
parameter names being adequately descriptive to obviate further documentation
(or else, it can be renamed, or a minimal single line may suffice)
I'm not entirely sold on the idea of globally enabling/disabling limits either,
but perhaps it might make sense to permit switching on/off categories of limit
(warn, error, info etc)?
> 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
