I am personally ready to give you my vote :-) On Wed, 10 Nov 2021 at 13:09, Andrés de la Peña <adelap...@apache.org> wrote:
> I think the updated CEP incorporates the feedback above, unless I'm missing > something. Are we ready to start a vote? > > On Tue, 2 Nov 2021 at 15:54, Andrés de la Peña <adelap...@apache.org> > 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. > > > > > > I have updated the CEP to include those thresholds among the ones that > > could be migrated once we have the guardrails framework ready. I have > also > > mentioned the usage of internal messaging to be able to propagate the > > outcome of guardrails triggered on nodes that are not the coordinator, > and > > the need of making changes on drivers. > > > > What I meant by "and also to the client connection when applicable" is > > that some guardrails can be applied to things that are nor necessarily > > associated to a client connection, such as compaction. I have tried to be > > more explicit about that. > > > > > > On Tue, 2 Nov 2021 at 12:53, Andrés de la Peña <a.penya.gar...@gmail.com > > > > wrote: > > > >> Being able to configure guardrails dynamically makes a lot of sense to > >> me, I have updated the CEP to mention that. I think we don't need to > decide > >> yet whether it would be done through JMX and/or virtual tables. > >> > >> On Mon, 1 Nov 2021 at 20:35, C. Scott Andreas <sc...@paradoxica.net> > >> wrote: > >> > >>> Re: "I think you all know my feels on JMX." – > >>> > >>> Super fair - I'd meant to speak in terms of desired outcome ("the > >>> feature should be dynamically configurable at runtime") rather than > >>> implementation ("this should be via JMX"). 👍 > >>> > >>> On Nov 1, 2021, at 1:24 PM, David Capwell <dcapw...@apple.com.INVALID> > >>> wrote: > >>> > >>> > >>> If anyone wants to bite off making > >>> > https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java > >>> < > >>> > https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java > > > >>> support mutability then we get vtable support. I am cool with JMX > and/or > >>> vtable, to me its just more important to allow dynamic setting of these > >>> configs. > >>> > >>> On Nov 1, 2021, at 10:36 AM, bened...@apache.org wrote: > >>> > >>> 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, > >>> > >>> > >>> > >>> > >>> > >>> >
