[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480136#comment-17480136
]
Josh McKenzie edited comment on CASSANDRA-17188 at 1/21/22, 3:28 PM:
---------------------------------------------------------------------
Thanks for that clarifying context Benedict.
{quote}Ideally, we would have design documents
{quote}
Hold on now, let's not get too wild here. ;)
What's the perceived work overhead / tension of refactoring whatever config
gets merged here w/regards to CASSANDRA-17212 and CASSANDRA-15234 if it hits
before they do, or the overhead of rebasing this on top of whatever we settle
on there authoritatively long-term if we move forward on all still and they
merge first?
ISTM the real risk here is this patch making it in before a major and
CASSANDRA-15234 _not_ making it leading to us releasing with a non-agreed upon
long-term config API commitment right? Perhaps the right choice is to just make
this ticket dependent on CASSANDRA-15234 and block merge of this on that so we
don't have a release get out with an API that's not widely agreed upon. We
could push this to "completion" and rebase it (sorry [~adelapena]) on top of
that one once it hits but more or less be ready to merge.
Also, in all seriousness, config parameters and formatting are (IMO) 100% an
API choice that has huge impacts on end users; it's one of the primary ways
operators interact with the system. We should think this out and have a design
doc where we talk through things high level instead of trawling through the mud
and trenches while trying to reason about it (like we so often do =/).
I'm operating under the assumption that's something we're going to
authoritatively determine separately and the work here will be deferring to
that in its final form.
was (Author: jmckenzie):
Thanks for that clarifying context Benedict.
{quote}Ideally, we would have design documents
{quote}
Hold on now, let's not get crazy here. ;)
What's the perceived work overhead / tension of refactoring whatever config
gets merged here w/regards to CASSANDRA-17212 and CASSANDRA-15234 if it hits
before they do, or the overhead of rebasing this on top of whatever we settle
on there authoritatively long-term if we move forward on all still and they
merge first?
ISTM the real risk here is this patch making it in before a major and
CASSANDRA-15234 _not_ making it leading to us releasing with a non-agreed upon
long-term config API commitment right? Perhaps the right choice is to just make
this ticket dependent on CASSANDRA-15234 and block merge of this on that so we
don't have a release get out with an API that's not widely agreed upon. We
could push this to "completion" and rebase it (sorry [~adelapena]) on top of
that one once it hits but more or less be ready to merge.
Also, in all seriousness, config parameters and formatting are (IMO) 100% an
API choice that has huge impacts on end users; it's one of the primary ways
operators interact with the system. We should think this out and have a design
doc where we talk through things high level instead of trawling through the mud
and trenches while trying to reason about it (like we so often do =/).
I'm operating under the assumption that's something we're going to
authoritatively determine separately and the work here will be deferring to
that in its final form.
> 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: [email protected]
For additional commands, e-mail: [email protected]
