via JMX").
>> >>>>>
>> >>>>> On Nov 1, 2021, at 1:24 PM, David Capwell
>>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> If anyone wants to bite off making
>>
gt;> wrote:
> >>>>>
> >>>>>
> >>>>> If anyone wants to bite off making
> >>>>>
> >>
> https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/Settings
42b8e74cbf0a0a/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
>>
he/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 d
hen 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 y
figuration 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
>> Date: Monday, 1 November 2021
this is the right place to bite this
> off, but perhaps?
>
> From: Jeff Jirsa
> Date: Monday, 1 November 2021 at 16:47
> To: Cassandra DEV
> Subject: Re: [DISCUSS] CEP-3: Guardrails
> Without bike-shedding too much, guardrails would be great, building them
> into a more
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
wrote:If anyone wants to bite
perhaps?
>
> From: Jeff Jirsa
> Date: Monday, 1 November 2021 at 16:47
> To: Cassandra DEV
> 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
off, but perhaps?
From: Jeff Jirsa
Date: Monday, 1 November 2021 at 16:47
To: Cassandra DEV
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 fantas
"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
wrote:
> Thank you for starting discussion on this CEP, Andrés!
>
>
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:
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
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 (
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
15 matches
Mail list logo
