I fully understand you. Although I have that luxury to use more containers,
I simply feel that rerunning the same code with different configurations
which do not impact that code is just a waste of resources and money.
- - -- --- - -
Jacek Lewandowski
czw., 15 lut 2024
By the way, I am not sure if it is all completely transparent and
understood by everybody but let me guide you through a typical patch which
is meant to be applied from 4.0 to trunk (4 branches) to see how it looks
like.
I do not have the luxury of running CircleCI on 100 containers, I have just
>
> Excellent point, I was saying for some time that IMHO we can reduce
> to running in CI at least pre-commit:
> 1) Build J11 2) build J17
> 3) run tests with build 11 + runtime 11
> 4) run tests with build 11 and runtime 17.
Ekaterina, I was thinking more about:
1) build J11
2) build J17
3)
Something along what Paulo is proposing makes sense to me. To sum it up,
knowing what workflows we have now:
java17_pre-commit_tests
java11_pre-commit_tests
java17_separate_tests
java11_separate_tests
We would have couple more, together like:
java17_pre-commit_tests
> Perhaps it is also a good opportunity to distinguish subsets of tests
which make sense to run with a configuration matrix.
Agree. I think we should define a “standard/golden” configuration for each
branch and minimally require precommit tests for that configuration.
Assignees and reviewers can
> If there’s an “old compatible default” and “latest recommended settings”,
when does the value in “old compatible default” get updated? Never?
How about replacing cassandra.yaml with cassandra_latest.yaml on trunk when
cutting cassandra-6.0 branch? Any new default changes on trunk go to
I share Jacek’s and Stefan’s sentiment about the low value of requiring
precommit j11+j17 tests for all changes.
Perhaps this was needed during j17 stabilization but is no longer required?
Please correct if I’m missing some context.
To have a practical proposal to address this, how about:
1)
Jon,
I was mostly referring to Circle CI where we have two pre-commit workflows.
(just click on anything here
https://app.circleci.com/pipelines/github/instaclustr/cassandra)
java17_pre-commit_tests
This workflow is compiling & testing everything with Java 17
java11_pre-commit_tests
This
>
> I'm ok with breaking trunk CI temporarily as long as failures are tracked
> and triaged/addressed before the next release.
>From the ticket, I understand it is meant for 5.0-rc
I share this sentiment for the release we decide to ship with:
> The failures should block release or we should
Stefan, can you elaborate on what you are proposing? It's not clear (at
least to me) what level of testing you're advocating for. Dropping testing
both on dev branches, every commit, just on release? In addition, can you
elaborate on what is a hassle about it? It's been a long time since I
I agree with Jacek, I don't quite understand why we are running the
pipeline for j17 and j11 every time. I think this should be opt-in.
Majority of the time, we are just refactoring and coding stuff for
Cassandra where testing it for both jvms is just pointless and we _know_
that it will be fine
śr., 14 lut 2024 o 17:30 Josh McKenzie napisał(a):
> When we have failing tests people do not spend the time to figure out if
> their logic caused a regression and merge, making things more unstable… so
> when we merge failing tests that leads to people merging even more failing
> tests...
>
>
1) If there’s an “old compatible default” and “latest recommended settings”,
when does the value in “old compatible default” get updated? Never?
2) If there are test failures with the new values, it seems REALLY IMPORTANT to
make sure those test failures are discovered + fixed IN THE FUTURE
The Cassandra team is pleased to announce the release of Apache Cassandra
version 4.1.4.
Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.
https://cassandra.apache.org/
Downloads of source
Cool stuff! This will make it easier to advance configuration defaults
without affecting stable configuration.
Wording looks good to me. +1 to include a NEWS.txt note. I'm ok with
breaking trunk CI temporarily as long as failures are tracked and
triaged/addressed before the next release.
I
> When we have failing tests people do not spend the time to figure out if
> their logic caused a regression and merge, making things more unstable… so
> when we merge failing tests that leads to people merging even more failing
> tests...
What's the counter position to this Jacek / Berenguer?
The vote has passed with three binding +1s and no vetoes.
Hi,
I think what Gaurav means is what we know at DataStax as transitional
authenticator, which temporarily allows for partially enabled
authentication - when the system allows the clients to authenticate but
does not enforce it.
All in all, that should be included in CEP-31 - also CEP-31 aims to
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- source
+1 to not doing, imo, the ostrich lol
On 14/2/24 10:58, Jacek Lewandowski wrote:
We should not block merging configuration changes given it is a valid
configuration - which I understand as it is correct, passes all config
validations, it matches documented rules, etc. And this provided
latest
We should not block merging configuration changes given it is a valid
configuration - which I understand as it is correct, passes all config
validations, it matches documented rules, etc. And this provided latest
config matches those requirements I assume.
The failures should block release or we
Wording looks good to me. I would also put that into NEWS.txt but I am not
sure what section. New features, Upgrading nor Deprecation does not seem to
be a good category.
On Tue, Feb 13, 2024 at 5:42 PM Branimir Lambov wrote:
> Hi All,
>
> CASSANDRA-18753 introduces a second set of defaults (in
is there a reason all guardrails and reliability (aka repair retries)
configs are off by default? They are off by default in the normal config
for backwards compatibility reasons, but if we are defining a config saying
what we recommend, we should enable these things by default IMO.
This is one
23 matches
Mail list logo
