> having them only configured via yaml seems like a bad outcome +1
I would like to see us move towards configuration being driven through virtual tables where possible, so that the whole cluster can be managed from a single interface. Not sure if this is the right place to bite this off, but perhaps? From: Jeff Jirsa <jji...@gmail.com> Date: Monday, 1 November 2021 at 16:47 To: Cassandra DEV <dev@cassandra.apache.org> Subject: Re: [DISCUSS] CEP-3: Guardrails 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, >
