>
> I don’t think means guaranteeing there are no failing tests (though
> ideally this would also happen), but about ensuring our best practices are
> followed for every merge. 4.0 took so long to release because of the amount
> of hidden work that was created by merging work that didn’t meet the
> I have to apologise here. CircleCI did not uncover these problems, apparently
> due to some way it resolves dependencies,
I double checked your CircleCI run for the trunk branch, and the problem
doesn’t have to do with “resolves dependencies”, the problem lies with our CI
being too complex
> How do we define what "releasable trunk" means?
One thing I would love is for us to adopt a “run all tests needed to release
before commit” mentality, and to link a successful run in JIRA when closing (we
talked about this once in slack). If we look at CircleCI we currently do not
run all
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
If anyone wants to bite off making
https://github.com/apache/cassandra/blob/ab920c30310a8c095ba76b363142b8e74cbf0a0a/src/java/org/apache/cassandra/db/virtual/SettingsTable.java
> 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
"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 (
Inline
> On Nov 1, 2021, at 9:23 AM, Branimir Lambov wrote:
>
> As Jacek is not a committer, this proposal needs a shepherd. I would be
> happy to take this role.
>
>> to me the interfaces has to be at the SSTable level, which then expose
> readers/writers, but also has to expose the other
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
As Jacek is not a committer, this proposal needs a shepherd. I would be
happy to take this role.
> to me the interfaces has to be at the SSTable level, which then expose
readers/writers, but also has to expose the other things we do outside of
those paths
Could you give some detail on what these
Hi all,
I have just created CASSANDRA-17113 adding scripting options to select the
workflow to be used, trying to implement Benedict's suggestion.
It adds some flags to the existing .circleci/generate.sh config generation
script. A -p flag generates only the pre-commit workflows, whereas a -s
14 matches
Mail list logo
