"it will be important that these guardrails can be modified via JMX as well"
I think you all know my feels on JMX. Maybe this is something we can go straight to virtual tables? On Mon, Nov 1, 2021 at 12:12 PM C. Scott Andreas <sc...@paradoxica.net> wrote: > 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+Guardrails > > Re: 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 them > into a more general purpose framework that limits various dangerous things > would be fantastic. The CEP says that the guardrails should be distinct > from the capability restrictions ( > https://issues.apache.org/jira/browse/CASSANDRA-8303 ), but I don't see > why > that needs to be the case. A system-level guardrail and a personal-level > guardrail are both restrictions, they just have different scopes, so > implement the restriction framework first, and allow the scopes to be > expanded 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 yaml > seems like a bad outcome > > > > https://issues.apache.org/jira/browse/CASSANDRA-8303 > > > > On 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+Guardrails > > Guardrails are an easy way to enforce system-wide soft and hard limits to > prevent anti-patterns of bad usage and in the long run make it not possible > to severely degrade the performance of a node/cluster through user actions > such as having too many secondary indexes, too large partitions, almost > full disks, etc. > > Thanks, > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
