Re: Cassandra project status update 2022-08-03

“ In my opinion, not all flakies are equals. Some fails every 10 runs, some fails 1 in a 1000 runs.” Agreed, for all not new tests/regressions which are also not infra related. “ We can start by putting the bar at a lower level and raise the level over time when most of the flakies that we hit

Re: dtests to reproduce the schema disagreement

Stop node 1 before you start node 2, essentially mocking a full network partition. On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev wrote: > Thank you, Aleksey, > Yes, I have tried this approach, the problem is there is a timing window > that node 1 runs the CREATE TABLE while node 2 is

Re: dtests to reproduce the schema disagreement

Thank you, Aleksey, Yes, I have tried this approach, the problem is there is a timing window that node 1 runs the CREATE TABLE while node 2 is down, and then we bring up the node 2 and it may receive the gossip from node 1 at startup, and the CREATE TABLE will fail on node 2 since the table

Re: Unsubscribe

To unsubscribe from this mailing list, you'll need to send an email to dev-unsubscr...@cassandra.apache.org On 09/08/2022 12:52, Schmidtberger, Brian M. (STL) wrote: unsubscribe + BRIAN SCHMIDTBERGER Software Engineering Senior Advisor, Core Engineering, Express Scripts M: 785.766.7450

Re: Cassandra project status update 2022-08-03

At this point it is clear that we will probably never be able to remove some level of flakiness from our tests. For me the questions are: 1) Where do we draw the line for a release ? and 2) How do we maintain that line over time? In my opinion, not all flakies are equals. Some fails every 10

Unsubscribe

unsubscribe + BRIAN SCHMIDTBERGER Software Engineering Senior Advisor, Core Engineering, Express Scripts M: 785.766.7450 EVERNORTH.COM Confidential, unpublished property of Evernorth. Do not duplicate or distribute. Use and distribution limited solely to authorized

Re: dtests to reproduce the schema disagreement

The absolute easiest way would be to down one of the two nodes first, run CREATE TABLE on the live node, shut it down, get the other one up, and run the same CREATE TABLE there, the bring up the down node. > On 9 Aug 2022, at 07:48, Konstantin Osipov via dev > wrote: > > * Cheng Wang via dev

Re: key apt by apache cassandra seems deprecated and cqlsh is broken

Could this be related to the deprecation of apt-key on your system? You don't specify what version of which distribution you are using. However, there is a good example of how to solve the issue at https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html On Tue, Aug 9, 2022

key apt by apache cassandra seems deprecated and cqlsh is broken

hello, i am getting this error when i try to update my system : '''W: http://www.apache.org/dist/cassandra/debian/dists/40x/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details. ''' (for this error on my ubuntu

Re: dtests to reproduce the schema disagreement

* Cheng Wang via dev [22/08/09 09:43]: > I am working on improving the schema disagreement issue. I need some dtests > which can reproduce the schema disagreement. Anyone know if there are any > existing tests for that? Or something similar? cassandra-10250 is a good start. -- Konstantin