Thank you for starting discussion on this CEP, Andrés!Can the "Scope" section of the doc be filled out? It currently reads "TBD," but
having a better understanding of the scope of work would help focus discussion: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+GuardrailsRe:
configuration via yaml, it will be important that these guardrails can be modified via JMX as well - e.g., in the case of a user running up against a limit
and needing a path to being unblocked that doesn't require a yaml change and rolling restart.As David mentions, raising the visibility of the soft limit
warnings will help users avoid being caught off-guard. Enabling the logging of wire protocol warnings received in CQL responses in the drivers by default
would help if related JIRA tickets in those projects can be considered.On Nov 1, 2021, at 10:05 AM, David Capwell <dcapw...@apple.com.INVALID>
wrote:Under "Migrating existing cassandra.yaml warn/fail thresholds”, I recently added a few things which are basically guardrails, so should be
included in this set; they are configured by track_warnings (coordinator_read_size, local_read_size, and row_index_size). With track_warnings I setup the
plumbing to have read queries trigger warnings (or abort the query) to the client exists (under "Event logging" you mention "and also to the
client connection when applicable”) and isn’t limited to the coordinator participating in the query (previous limitation for tombstone warnings). One thing
I found which was problematic for track_warnings was that altering clients is annoying as java and python both ignore the error message we send (see
https://github.com/datastax/java-driver/blob/3.11.0/driver-core/src/main/java/com/datastax/driver/core/Responses.java#L73-L131). We log client warnings (if
enabled) but ignore any detailed error message received from the server; it would be good to talk about client integrations and how users are informed of
issues in more detail.On Nov 1, 2021, at 9:46 AM, Jeff Jirsa <jji...@gmail.com> wrote:Without bike-shedding too much, guardrails would be great,
building theminto a more general purpose framework that limits various dangerous thingswould be fantastic. The CEP says that the guardrails should be
distinctfrom the capability restrictions (https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see whythat needs to be the case. A
system-level guardrail and a personal-levelguardrail are both restrictions, they just have different scopes, soimplement the restriction framework first, and
allow the scopes to beexpanded as needed?Naming wise, I don't know that I'd actually surface these as "guardrails",but more as general
"limits", and having them only configured via yamlseems like a bad outcomehttps://issues.apache.org/jira/browse/CASSANDRA-8303On Mon, Nov 1, 2021
at 9:31 AM Andrés de la Peña <adelap...@apache.org>wrote:Hi everyone,I'd like to start a discussion about Guardrails
proposal:https://cwiki.apache.org/confluence/display/CASSANDRA/%28DRAFT%29+-+CEP-3%3A+GuardrailsGuardrails are an easy way to enforce system-wide soft and
hard limits toprevent anti-patterns of bad usage and in the long run make it not possibleto severely degrade the performance of a node/cluster through user
actionssuch as having too many secondary indexes, too large partitions, almostfull disks,
etc.Thanks,---------------------------------------------------------------------To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.orgFor additional
commands, e-mail: dev-h...@cassandra.apache.org
