[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482623#comment-17482623
]
Caleb Rackliffe commented on CASSANDRA-17188:
---------------------------------------------
[~benedict] So what does this mean, in concrete terms? Is your ask essentially
that we come up with at least a _design_ for CASSANDRA-17292 (i.e. a design we
broadly agree on as a long term guide, but don't need to actually complete
until 5.0 at the earliest) and then make a reasonable effort to have guardrails
fit into that for 4.1 (where it will be released for the first time and not
create compatibility burdens)? If we can do that incrementally, I'm not opposed
to that strategy, assuming we actually want to move the config in that
direction in our lifetimes :)
[~adelapena] [~dcapwell] Thoughts?
> Guardrails for consistency levels
> ---------------------------------
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {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
