[
https://issues.apache.org/jira/browse/CASSANDRA-17147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17147:
--------------------------------------
Status: Review In Progress (was: Patch Available)
started first batch of review, left comments in PR but had a few high level ones
* Why try to offer a pluggable implementation for the leaf types? What value
do we get allowing a pluggable way to override how we check a volatile field?
* what are the plans for listeners? They are mostly dead code
* why 2 different configuration systems? I 100% get why you would want a new
MBean, but don't get why we need 2 different config systems: GuardrailOptions
vs GuardrailConfig
* ClientState being part of the base interface could become a problem when you
integrate with track_warnings, as they plugin to places shared by query and
background services (compaction/repair); not a blocker for this patch as you
have scoped moving track_warnings to guardrails, but just something to think
about
* some checks offer warn/fail, and others make this 2 different checks:
disallowTableProperties, etc. Should these not be simplified to a single check?
> Guardrails prototype
> --------------------
>
> Key: CASSANDRA-17147
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17147
> 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.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The purpose of this ticket is creating an initial implementation of the
> guardrails framework, as well as adding a few simple guardrails using this
> framework.
> To keep things easy, this initial implementation would only support
> guardrails that are triggered on the coordinator, and they would be
> dynamically updatable only through JMX.
> Once we have this initial framework ready in a feature branch we can have
> multiple tickets addressing all the things that would have been left out of
> the scope of this ticket, such as:
> * Dynamic updates through virtual tables
> * Being able to notify about guardrails triggered on replicas
> * Using custom exceptions other than {{InvalidRequestException}}.
> * Porting existing limits to use the new guardrails framework
> * Adding new guardrails beyond the initial ones
> The reason for having this simpler prototype is that it will give us a common
> ground to parallelize work on the parts mentioned above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
