[
https://issues.apache.org/jira/browse/CASSANDRA-17212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480345#comment-17480345
]
Caleb Rackliffe edited comment on CASSANDRA-17212 at 1/22/22, 4:47 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.
Agreed, but the logical conclusion of that feels like eventually dismembering
the top-level {{guardrails}} element in the current/trunk config. (I'm fine w/
this, to be clear.)
bq. Can we move this conversation/decision to its own JIRA/CEP that we vote on;
I feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
Either way, we're going to be forced to continue this discussion for some
things like CASSANDRA-17148. Looking at the example snippet you've posted
above, I think it would make a lot of sense to have the {{track_warnings}} bits
under a top-level {{query}} element. (We might say the same for
CASSANDRA-17188.) I'm writing up the skeleton of a new Jira that deals w/ the
overall structure of the config, and we can have a few proposals up there
shortly. Would it be feasible to converge on a specific-enough long-term plan
after some discussion there quickly enough to allow CASSANDRA-17148, et al. to
proceed coherently without too much delay?
was (Author: maedhroz):
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.
Agreed, but the logical conclusion of that feels like eventually dismembering
the top-level {{guardrails}} element in the current/trunk config. (I'm fine w/
this, to be clear.)
bq. Can we move this conversation/decision to its own JIRA/CEP that we vote on;
I feel that an extension to an existing feature isn't the best place for such
discussion. If you want to take on this work, I will support you.
Either way, we're going to be forced to continue this discussion for some
things like CASSANDRA-17148. Looking at the example snippet you've posted
above, I think it would make a lot of sense to have the {{track_warnings}} bits
under a top-level {{query}} element. (We might say the same for
CASSANDRA-17188.) I'm up the skeleton of a new Jira that deals w/ the overall
structure of the config, and we can have a few proposals up there shortly.
Would it be feasible to converge on a specific-enough long-term plan after some
discussion there quickly enough to allow CASSANDRA-17148, et al. to proceed
without burdensome delay?
> 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
