[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[ https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339997#comment-17339997 ] Berenguer Blasi commented on CASSANDRA-16625: - My bad lol! > Add a CircleCI job to run some tests repeatedly > --- > > Key: CASSANDRA-16625 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16625 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > I think it could be useful to have an optional CircleCI job to run some > specific tests n times. That way, tickets could attach CircleCI runs showing > that the changes don't make a certain ticket flaky or, conversely, that they > fix a flaky test. Doing this systematically should mitigate the risk of > introducing new flaky tests, and I guess it would be more convenient and easy > to share than running the tests locally or on a private CI system. > It would also be nice to have something similar in Jenkins, but I'm focusing > this ticket on CircleCI because it's available also for non-committers, so > assignees can run their tests before setting the tickets as ready for review. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339996#comment-17339996
]
Berenguer Blasi commented on CASSANDRA-16644:
-
Hi [~e.dimitrova] thx for looking into this. I was buried yesterday and
couldn't look much but I hope to do so today. Yes the 'flaky' annotation will
either be removed or moved to '2' once we reach a conclusion.
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339993#comment-17339993 ] Berenguer Blasi edited comment on CASSANDRA-16648 at 5/6/21, 4:35 AM: -- Squashed and running final CIs: - https://ci-cassandra.apache.org/job/Cassandra-devbranch/735/ - https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/ was (Author: bereng): Running final CIs: - https://ci-cassandra.apache.org/job/Cassandra-devbranch/735/ - https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/ > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.x > > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339993#comment-17339993 ] Berenguer Blasi commented on CASSANDRA-16648: - Running final CIs: - https://ci-cassandra.apache.org/job/Cassandra-devbranch/735/ - https://ci-cassandra.apache.org/job/Cassandra-devbranch/736/ > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.x > > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339478#comment-17339478 ] Berenguer Blasi edited comment on CASSANDRA-16648 at 5/6/21, 4:21 AM: -- [~mck] I am putting this up for review with the following proposal: - Merge my current [PR|https://github.com/apache/cassandra-dtest/pull/134] - CASSANDRA-16653 for the remaining non obvious failure Before merging I will run 2 devbranch runs in CI against trunk and 4.0 to make sure I didn't brake anything. was (Author: bereng): [~mck] I am putting this up for review with the following proposal: - Merge my current [PR|https://github.com/apache/cassandra-dtest/pull/134] - CASSANDRA-16653 for the remaining non obvious failure Before merging I will run 2 devbranch runs in CI against truck and 4.0 to make sure I didn't brake anything. > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.x > > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16655:
Authors: Berenguer Blasi, Michael Semb Wever
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339987#comment-17339987
]
Berenguer Blasi commented on CASSANDRA-16655:
-
Just checked latest jobs. It works! :-) Thanks for taking it over the finish
line!
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339943#comment-17339943
]
Ekaterina Dimitrova edited comment on CASSANDRA-16644 at 5/6/21, 12:08 AM:
---
That is so weird, I tried to push two times 1000 runs since last night, same
config and same jobs on java 11 as [~adelapena] and I can't reproduce anything.
I would like to suggest this [tiny patch
|https://github.com/ekaterinadimitrova2/ccm/commit/3f4ba3597f0809201f88dae403a15c33d12dd021]
which in case the test fails again will help us to see where it was. The
_Tail_ added before is actually _Head_ so I decided to add both.
I think having both would be good for debugging in such weird cases. WDYT?
Also, on the additional topic I brought, I think it is meaningless to keep
_@flaky(max_runs=1)_, either we should consider there was a mistake and 2 was
aimed or we can remove it to prevent further confusion. WDYT?
was (Author: e.dimitrova):
That is so weird, I tried to push two times 1000 runs since last night, same
config and same jobs on java 11 as [~adelapena] and I can't reproduce anything.
I would like to suggest this [tiny patch
|https://github.com/ekaterinadimitrova2/ccm/commit/3f4ba3597f0809201f88dae403a15c33d12dd021]
which in case it fails again will help us to see where it was. The _Tail_
added before is actually _Head_ so I decided to add both.
I think having both would be good for debugging in such weird cases. WDYT?
Also, on the additional topic I brought, I think it is meaningless to keep
_@flaky(max_runs=1)_, either we should consider there was a mistake and 2 was
aimed or we can remove it to prevent further confusion. WDYT?
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'
[jira] [Commented] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339943#comment-17339943
]
Ekaterina Dimitrova commented on CASSANDRA-16644:
-
That is so weird, I tried to push two times 1000 runs since last night, same
config and same jobs on java 11 as [~adelapena] and I can't reproduce anything.
I would like to suggest this [tiny patch
|https://github.com/ekaterinadimitrova2/ccm/commit/3f4ba3597f0809201f88dae403a15c33d12dd021]
which in case it fails again will help us to see where it was. The _Tail_
added before is actually _Head_ so I decided to add both.
I think having both would be good for debugging in such weird cases. WDYT?
Also, on the additional topic I brought, I think it is meaningless to keep
_@flaky(max_runs=1)_, either we should consider there was a mistake and 2 was
aimed or we can remove it to prevent further confusion. WDYT?
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16652) "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
[
https://issues.apache.org/jira/browse/CASSANDRA-16652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339936#comment-17339936
]
Ekaterina Dimitrova commented on CASSANDRA-16652:
-
Thank you both.
So from what I here we have two options - backward compatibility or to add a
proper warning in 4.0 to prevent further confusion.
I am also interested as [~blerer] to hear what [~cnlwsu] and [~jolynch] think.
> "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
> -
>
> Key: CASSANDRA-16652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16652
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2
>
>
> The "desc" statement on cqlsh 6.0.0 shipped with Cassandra 4.0 RC1 is not
> working correctly when it's connected to a Cassandra 3.x server.
> Steps to reproduce:
> * Ensure you have docker installed and running
> * Run the following docker commands to create and start a Cassandra 3.11
> container
> {code:java}
> ~ $ docker create --name cassandra3 cassandra:3.11.10
> 5d903e48e0661e39080198de5e8752356a5a666132211a500ea38af0fc2a0356
> ~ $ docker start cassandra3
> cassandra3
> ~ $ docker exec -ti cassandra3 bash
> {code}
> * Inside the docker container, try the default cqlsh version, make sure
> everything is working correctly
> {code:java}
> root@5d903e48e066:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> system_traces system_schema system_auth system system_distributed
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> resource_role_permissons_index role_permissions role_members roles
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> {code}
> * Okay, everything worked as expected. Now install {{git}} to clone the
> Cassandra 4.0 RC1 source code, and {{python3-six}}, which is a dependency of
> cqlsh
> {code:java}
> root@5d903e48e066:/# apt-get update -qq && apt-get install -qq git python3-six
> .. [truncated]
> {code}
> * Clone the Cassandra repository and checkout the cassandra-4.0-rc1 tag
> {code:java}
> root@5d903e48e066:/# git clone -b cassandra-4.0-rc1 --depth 1
> https://github.com/apache/cassandra.git cassandra-4.0-rc1
> Cloning into 'cassandra-4.0-rc1'...
> .. [truncated]
> {code}
> * Run the cqlsh from the Git repository, and then repeat all the cqlsh
> statements above
> {code:java}
> root@5d903e48e066:/# cd cassandra-4.0-rc1/bin
> root@5d903e48e066:/cassandra-4.0-rc1/bin# ./cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> root@5d903e48e066:/cassandra-4.0-rc1/bin#
> {code}
> "desc" did not work correctly, but "use" and "select" worked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16613) ProtocolVersion.V4 is still used in places in the code
[ https://issues.apache.org/jira/browse/CASSANDRA-16613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339934#comment-17339934 ] Ekaterina Dimitrova commented on CASSANDRA-16613: - Thank you [~samt]! I rebased my branch. There is some issue in CircleCI not related to this ticket but preventing us from getting the right picture, I just submitted Jenkins run [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/734/] > ProtocolVersion.V4 is still used in places in the code > -- > > Key: CASSANDRA-16613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16613 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc2, 4.0-rc > > > While working on CASSANDRA-16567, [~adelapena] observed that > _ProtocolVersion.V4_ is used in _ViewTest_. > I decided to do a quick grep and observed a list of places where we still > refer to V4 and it seems at least in many of the tests that was left not > intentionally. > This ticket is to verify the usage of _ProtocolVersion.V4_ in the codebase > and bump it to V5 or default version, similar to what was done in > CASSANDRA-16567, wherever there is a need. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339909#comment-17339909
]
Ekaterina Dimitrova commented on CASSANDRA-16643:
-
Thanks for the heads up. Seems like there was issue with my token maybe.
I just submitted it again
[here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/733/console] and
it seems that now it worked
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339903#comment-17339903
]
Adam Holmberg commented on CASSANDRA-16643:
---
Thanks, but looks like that one failed on github clone.
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16643:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Ekaterina Dimitrova, Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339897#comment-17339897
]
Ekaterina Dimitrova commented on CASSANDRA-16643:
-
Seems it is just Circle CI issue, I am pushing CI run to Jenkins while we fix
the Circle issue:
https://jenkins-cm4.apache.org/job/Cassandra-devbranch/732/
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16582) Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version cluster
[
https://issues.apache.org/jira/browse/CASSANDRA-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339896#comment-17339896
]
junwen yang commented on CASSANDRA-16582:
-
Based on this, we found there are several other enums using orders to conduct
serialization/deserialization, such as:
TraceType in cassandra/src/java/org/apache/cassandra/tracing/Tracing.java
Kind in
cassandra/src/java/org/apache/cassandra/db/filter/ColumnSubselection.java.
Current TraceType and Kind hasn't been changed for a while, but I believe a
comments stating that "their order is used in serialization, and don't change
it" will be helpful for further code practice.
> Groupby queries trigger ArrayIndexOutOfBoundsException on mixed version
> cluster
> ---
>
> Key: CASSANDRA-16582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16582
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: junwen yang
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0, 4.0-rc1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When I have a mixed cluster with C*3.10 and C*4.0-beta4, issuing GROUP BY
> query to 3.10 will trigger `java.lang.ArrayIndexOutOfBoundsException`.
> Reproduce:
> having a mixed cluster 3.10 and 4.0-beta4
>
> {code:java}
> // create keyspace and db
> cqlsh> CREATE KEYSPACE test WITH replication = {'class':'SimpleStrategy',
> 'replication_factor' : 1};
> cqlsh> use test;
> cqlsh:test> create table login_log ( user_id int, application_name text,
> primary key (user_id, application_name) ) with clustering order by
> (application_name asc);
> cqlsh:test> insert into login_log (user_id, application_name) VALUES(1,
> 'bash');cqlsh:test> insert into login_log (user_id, application_name)
> VALUES(1, 'chrome');
> // issue GROUP BY QUERY
> cqlsh:test> select user_id, application_name from login_log group by user_id,
> application_name;{code}
>
> The reason why the bug happens is that the Kind enum in DataLimits has
> changed from 6 values to 4 values:
>
> {code:java}
> [THRIFT_LIMIT, SUPER_COLUMN_COUNTING_LIMIT, CQL_GROUP_BY_LIMIT,
> CQL_GROUP_BY_PAGING_LIMIT]{code}
> {code:java}
> [CQL_LIMIT, CQL_PAGING_LIMIT, CQL_GROUP_BY_LIMIT, CQL_GROUP_BY_PAGING_LIMIT]
>
> {code}
> Thus when node 3.10 forwards the read command with CQL_GROUP_BY_LIMIT to node
> 4.0, it tries to read the value of index 4 in Kind which has only 4 elements,
> causing ArrayIndexOutOfBoundsException
> Log details:
> {code:java}
> ERROR [Messaging-EventLoop-3-5] 2021-04-09 00:27:14,899
> InboundMessageHandler.java:334 -
> /251.250.238.1:7000->/251.250.238.2:7000-LEGACY_MESSAGES-c356fde1 unexpected
> exception caught while deserializing a message
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.cassandra.db.filter.DataLimits$Serializer.deserialize(DataLimits.java:1172)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:1006)
> at
> org.apache.cassandra.db.ReadCommand$Serializer.deserialize(ReadCommand.java:909)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePayloadPre40(Message.java:966)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:947)
> at
> org.apache.cassandra.net.Message$Serializer.deserializePre40(Message.java:935)
> at
> org.apache.cassandra.net.Message$Serializer.deserialize(Message.java:635)
> at
> org.apache.cassandra.net.InboundMessageHandler.processSmallMessage(InboundMessageHandler.java:320)
> at
> org.apache.cassandra.net.InboundMessageHandler.processOneContainedMessage(InboundMessageHandler.java:303)
> at
> org.apache.cassandra.net.InboundMessageHandler.processFrameOfContainedMessages(InboundMessageHandler.java:270)
> at
> org.apache.cassandra.net.InboundMessageHandler.processIntactFrame(InboundMessageHandler.java:255)
> at
> org.apache.cassandra.net.InboundMessageHandler.process(InboundMessageHandler.java:246)
> at
> org.apache.cassandra.net.FrameDecoder.deliver(FrameDecoder.java:320)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:284)
> at
> org.apache.cassandra.net.FrameDecoder.channelRead(FrameDecoder.java:268)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRe
[jira] [Updated] (CASSANDRA-16654) Junit RepeatableRunner flaky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-16654: -- Summary: Junit RepeatableRunner flaky tests helper (was: Junit RepeatableRunner falky tests helper) > Junit RepeatableRunner flaky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339886#comment-17339886
]
Ekaterina Dimitrova commented on CASSANDRA-16643:
-
I also have all python dtests and cqlsh tests failing. Not sure whether it is
related to the latest patch 5 hours ago. I will test it now
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16643:
--
Test and Documentation Plan: new unit test added
Status: Patch Available (was: In Progress)
I'm passing this along with python dtests blown up by something else. CI shows
java unit and dtests in good shape.
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16643) ALTER TABLE: mixing counter and non-counter columns in one table
[
https://issues.apache.org/jira/browse/CASSANDRA-16643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339875#comment-17339875
]
Adam Holmberg commented on CASSANDRA-16643:
---
It seems some validation was omitted during some refactoring for 4.0. Proposed
patch adds metadata validation to AlterTableStatement, and a small unit test.
[patch|https://github.com/aholmberg/cassandra/pull/59]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16643]
> ALTER TABLE: mixing counter and non-counter columns in one table
> -
>
> Key: CASSANDRA-16643
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16643
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Artem Chebotko
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
>
> {{CREATE TABLE}} does not allow mixing counter and non-counter columns in the
> same table. However, this can be done with {{ALTER TABLE}}:
> * {{ALTER TABLE}} can add non-counter columns to a table with counter
> columns;
> * {{ALTER TABLE}} can add counter columns to a table with non-counter columns.
> Tested in cassandra-4.0-rc1 (also in cassandra-4.0-beta2):
> {code:sql}
> CREATE TABLE test1 (
> id UUID,
> my_counter COUNTER,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test1 ADD my_text TEXT;
> UPDATE test1
> SET my_counter = my_counter + 10,
> my_text = 'Test 1'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test1;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 10 | Test 1
> {code}
>
> {code:sql}
> CREATE TABLE test2 (
> id UUID,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> ALTER TABLE test2 ADD my_counter COUNTER;
> UPDATE test2
> SET my_counter = my_counter + 20,
> my_text = 'Test 2'
> WHERE id = 5069cc15-4300-4595-ae77-381c3af5dc5e;
> SELECT * FROM test2;
> id | my_counter | my_text
> --++-
> 5069cc15-4300-4595-ae77-381c3af5dc5e | 20 | Test 2
> {code}
>
> {code:sql}
> CREATE TABLE test3 (
> id UUID,
> my_counter COUNTER,
> my_text TEXT,
> PRIMARY KEY ((id))
> );
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
> mix counter and non counter columns in the same table"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16604) Parallelise docker container runs for tests in ci-cassandra.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16604: --- Fix Version/s: 4.x > Parallelise docker container runs for tests in ci-cassandra.a.o > --- > > Key: CASSANDRA-16604 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16604 > Project: Cassandra > Issue Type: Task > Components: CI, Test/unit >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 2.2.x, 3.0.x, 3.11.x, 4.0.x, 4.x > > Attachments: image-2021-04-28-09-41-20-310.png > > > This was raised on the dev ML, where the consensus was to remove it: > https://lists.apache.org/thread.html/r1ca3c72b90fa6c57c1cb7dcd02a44221dcca991fe7392abd8c29fe95%40%3Cdev.cassandra.apache.org%3E > The idea is to then replace ant test parallelism with docker container > parallelism. > PoC patch: > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16587-2/trunk > This is just a quick PoC, aimed at the ci-cassandra agents that have > 4 cores and 16gb ram available to each executor, but I imagine instead > something that spawns a number of containers based on system > resources, like we currently do with get-cores and get-mem. > Also worth noting the overhead here, compared with the ant parallelism > approach, docker > builds everything in each container from scratch, but this too can be > improved easily enough. > Cleaning up any remnant `-Dtest.runners=` options is also part of this ticket. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16121: --- Fix Version/s: 4.0 > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0, 4.0-beta4 > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Fix Version/s: (was: 4.0-rc)
(was: 4.x)
4.1
4.0
4.0-rc2
Since Version: 4.0-beta4
Source Control Link:
https://github.com/apache/cassandra/commit/b67d04b6fe311d8c923d125c722e7a094a921f0c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16121: --- Source Control Link: https://github.com/apache/cassandra/commit/0700d795bcc4d79c3f2e52872ac865fa735917d8 (was: https://github.com/apache/cassandra/commit/530179c7afe6e86c0bd84e5f4557345c93fcbc0a) > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0, 4.0-beta4 > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16121: --- Fix Version/s: (was: NA) 4.0-beta4 > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-beta4 > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Status: Ready to Commit (was: Review In Progress)
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Reviewers: Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Michael Semb Wever, Michael Semb Wever (was: Michael Semb Wever)
Status: Review In Progress (was: Patch Available)
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f55baa4dbf868b2ef6284d5a887f6d76e62944fd Merge: 642e95a b67d04b Author: Mick Semb Wever AuthorDate: Wed May 5 18:07:12 2021 +0200 Merge branch 'cassandra-4.0' into trunk pylib/cassandra-cqlsh-tests.sh | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (642e95a -> f55baa4)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 642e95a Merge branch 'cassandra-4.0' into trunk new b67d04b cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins new f55baa4 Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: pylib/cassandra-cqlsh-tests.sh | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new b67d04b cassandra-cqlsh-tests.sh should return different return codes
on circle vs jenkins
b67d04b is described below
commit b67d04b6fe311d8c923d125c722e7a094a921f0c
Author: Bereng
AuthorDate: Wed May 5 12:32:38 2021 +0200
cassandra-cqlsh-tests.sh should return different return codes on circle vs
jenkins
patch by Mick Semb Wever; reviewed by Berenguer Blasi for CASSANDRA-16655
---
pylib/cassandra-cqlsh-tests.sh | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 2458a3d..7904166 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -61,9 +61,10 @@ else
TESTSUITE_NAME="${TESTSUITE_NAME}.jdk8"
fi
+ant -buildfile ${CASSANDRA_DIR}/build.xml realclean
# Loop to prevent failure due to maven-ant-tasks not downloading a jar..
for x in $(seq 1 3); do
-ant -buildfile ${CASSANDRA_DIR}/build.xml realclean jar
+ant -buildfile ${CASSANDRA_DIR}/build.xml jar
RETURN="$?"
if [ "${RETURN}" -eq "0" ]; then
break
@@ -143,4 +144,10 @@ mv nosetests.xml ${WORKSPACE}/cqlshlib.xml
# /virtualenv
deactivate
-exit ${RETURN}
+# circleci needs non-zero exit on failures, jenkins need zero exit to process
the test failures
+if ! command -v circleci >/dev/null 2>&1
+then
+exit 0
+else
+exit ${RETURN}
+fi
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339740#comment-17339740
]
Michael Semb Wever commented on CASSANDRA-16655:
Patch:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:CASSANDRA-16655-trunk
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Test and Documentation Plan: Patch:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:CASSANDRA-16655-trunk
Status: Patch Available (was: In Progress)
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Test and Documentation Plan: (was: Patch:
https://github.com/apache/cassandra/compare/trunk...thelastpickle:CASSANDRA-16655-trunk)
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14701) Cleanup (and other) compaction type(s) not counted in compaction remaining time
[
https://issues.apache.org/jira/browse/CASSANDRA-14701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-14701:
Assignee: Brandon Williams
> Cleanup (and other) compaction type(s) not counted in compaction remaining
> time
> ---
>
> Key: CASSANDRA-14701
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14701
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: Thomas Steinmaurer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> Opened a ticket, as discussed in user list.
> Looks like compaction remaining time only includes compactions of type
> COMPACTION and other compaction types like cleanup etc. aren't part of the
> estimation calculation.
> E.g. from one of our environments:
> {noformat}
> nodetool compactionstats -H
> pending tasks: 1
>compaction type keyspace table completed totalunit
> progress
>CleanupXXX YYY 908.16 GB 1.13 TB bytes
> 78.63%
> Active compaction remaining time : 0h00m00s
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16656) Assertion Error on invalid ALTER TABLE Command
[
https://issues.apache.org/jira/browse/CASSANDRA-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16656:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.11.x
Severity: Normal (was: Low)
Status: Open (was: Triage Needed)
> Assertion Error on invalid ALTER TABLE Command
> --
>
> Key: CASSANDRA-16656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16656
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Norbert Schultz
>Priority: Low
> Fix For: 3.11.x
>
>
> If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
> responds with an assertion error.
>
> This happens on 3.11.10 but not on 4.0-rc1
> This statement fails:
> {code:java}
> > cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> use foo;
> cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
> cqlsh:foo> alter table test ADD (x INT, y INT,);
> ServerError: java.lang.AssertionError
> {code}
> The following can be found inside the Log:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.cql3.statements.AlterTableStatementColumn.(AlterTableStatementColumn.java:36)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.Cql_Parser.alterTableStatement(Cql_Parser.java:5820)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:628)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:604)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:344)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:589)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:559)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:685)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:591)
> [apache-cassandra-3.11.10.jar:3.11.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_292]
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:113)
> ~[apache-cassandra-3.11.10.jar:3.11.10]
> at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292]
> {code}
> Cassandra 4.0-rc1 responds as expected:
> {code}
> cqlsh:foo> alter table test ADD (x INT, y INT,);
> SyntaxException: line 1:35 no viable alternative at input ')' (...(x INT, y
> INT,[)]...)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16656) Assertion Error on invalid ALTER TABLE Command
[
https://issues.apache.org/jira/browse/CASSANDRA-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norbert Schultz updated CASSANDRA-16656:
Description:
If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
responds with an assertion error.
This happens on 3.11.10 but not on 4.0-rc1
This statement fails:
{code:java}
> cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> use foo;
cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
cqlsh:foo> alter table test ADD (x INT, y INT,);
ServerError: java.lang.AssertionError
{code}
The following can be found inside the Log:
{code}
java.lang.AssertionError: null
at
org.apache.cassandra.cql3.statements.AlterTableStatementColumn.(AlterTableStatementColumn.java:36)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.alterTableStatement(Cql_Parser.java:5820)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:628)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:604)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:344)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:589)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:559)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:685)
[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:591)
[apache-cassandra-3.11.10.jar:3.11.10]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_292]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:113)
~[apache-cassandra-3.11.10.jar:3.11.10]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292]
{code}
Cassandra 4.0-rc1 responds as expected:
{code}
cqlsh:foo> alter table test ADD (x INT, y INT,);
SyntaxException: line 1:35 no viable alternative at input ')' (...(x INT, y
INT,[)]...)
{code}
was:
If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
responds with an assertion error.
This happens on 3.11.10 but not on 4.0-rc1
This statement fails:
{code:java}
> cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> use foo;
cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
cqlsh:foo> alter table test ADD (x INT, y INT,);
ServerError: java.lang.AssertionError
{code}
The following can be found inside the Log:
{code}
java.lang.AssertionError: null
at
org.apache.cassandra.cql3.statements.AlterTableStatementColumn.(AlterTableStatementColumn.java:36)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.alterTableStatement(Cql_Parser.java:5820)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:628)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:604)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:344)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:589)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcesso
[jira] [Updated] (CASSANDRA-16656) Assertion Error on invalid ALTER TABLE Command
[
https://issues.apache.org/jira/browse/CASSANDRA-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norbert Schultz updated CASSANDRA-16656:
Severity: Low
Description:
If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
responds with an assertion error.
This happens on 3.11.10 but not on 4.0-rc1
This statement fails:
{code:java}
> cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> use foo;
cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
cqlsh:foo> alter table test ADD (x INT, y INT,);
ServerError: java.lang.AssertionError
{code}
The following can be found inside the Log:
{code}
java.lang.AssertionError: null
at
org.apache.cassandra.cql3.statements.AlterTableStatementColumn.(AlterTableStatementColumn.java:36)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.alterTableStatement(Cql_Parser.java:5820)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.Cql_Parser.cqlStatement(Cql_Parser.java:628)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.cqlStatement(CqlParser.java:604)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.cql3.CqlParser.query(CqlParser.java:344)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.CQLFragmentParser.parseAnyUnhandled(CQLFragmentParser.java:76)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:589)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:559)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:247)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.cql3.QueryProcessor.process(QueryProcessor.java:241)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.messages.QueryMessage.execute(QueryMessage.java:116)
~[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.Message$Dispatcher.processRequest(Message.java:685)
[apache-cassandra-3.11.10.jar:3.11.10]
at
org.apache.cassandra.transport.Message$Dispatcher.lambda$channelRead0$0(Message.java:591)
[apache-cassandra-3.11.10.jar:3.11.10]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_292]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.10.jar:3.11.10]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:113)
~[apache-cassandra-3.11.10.jar:3.11.10]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_292]
{code}
was:
If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
responds with an assertion error.
This happens on 3.11.10 but not on 4.0-rc1
This statement fails:
{code:java}
> cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> use foo;
cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
cqlsh:foo> alter table test ADD (x INT, y INT,);
ServerError: java.lang.AssertionError
{code}
> Assertion Error on invalid ALTER TABLE Command
> --
>
> Key: CASSANDRA-16656
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16656
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Norbert Schultz
>Priority: Low
>
> If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
> responds with an assertion error.
>
> This happens on 3.11.10 but not on 4.0-rc1
> This statement fails:
> {code:java}
> > cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> use foo;
> cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
> cqlsh:foo> alter table test ADD (x INT, y INT,);
> ServerError: java.lang.AssertionError
> {code}
> The following can be found inside the Log:
> {code}
> java.lang.AssertionError: null
> at
> org.apache.cassandra.cql3.statements.AlterTableStatementColumn.(AlterTableStatementColumn.java:36)
> ~[apache-cassandra-3.11.10.jar:3.
[jira] [Created] (CASSANDRA-16656) Assertion Error on invalid ALTER TABLE Command
Norbert Schultz created CASSANDRA-16656:
---
Summary: Assertion Error on invalid ALTER TABLE Command
Key: CASSANDRA-16656
URL: https://issues.apache.org/jira/browse/CASSANDRA-16656
Project: Cassandra
Issue Type: Bug
Components: CQL/Syntax
Reporter: Norbert Schultz
If there is an invalid ALTER TABLE statement (extra comma), then Cassandra
responds with an assertion error.
This happens on 3.11.10 but not on 4.0-rc1
This statement fails:
{code:java}
> cqlsh
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE foo WITH REPLICATION = { 'class' : 'SimpleStrategy',
'replication_factor' : 1 };
cqlsh> use foo;
cqlsh:foo> create table test(id INT, PRIMARY KEY(id));
cqlsh:foo> alter table test ADD (x INT, y INT,);
ServerError: java.lang.AssertionError
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339682#comment-17339682
]
Michael Semb Wever commented on CASSANDRA-16655:
tested:
- (circleci intentional fail)
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/26/workflows/f9ee119c-9b69-46fa-8fab-fc06614d1a8e/jobs/416
- (circleci pass)
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/24/workflows/bb8ce7be-7f41-4107-85de-cfb5ab32f3c4/jobs/390
- (ci-cassandra unstable)
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-cqlsh-tests/738/
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16655:
---
Fix Version/s: (was: 4.0-rc2)
4.0-rc
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16652) "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
[
https://issues.apache.org/jira/browse/CASSANDRA-16652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339631#comment-17339631
]
Brandon Williams commented on CASSANDRA-16652:
--
bq. The other option is to not support that feature and warn the user in the
upgrade section
I think it should be possible to detect it in cqlsh when it happens and warn
the user there that it doesn't work as well.
> "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
> -
>
> Key: CASSANDRA-16652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16652
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2
>
>
> The "desc" statement on cqlsh 6.0.0 shipped with Cassandra 4.0 RC1 is not
> working correctly when it's connected to a Cassandra 3.x server.
> Steps to reproduce:
> * Ensure you have docker installed and running
> * Run the following docker commands to create and start a Cassandra 3.11
> container
> {code:java}
> ~ $ docker create --name cassandra3 cassandra:3.11.10
> 5d903e48e0661e39080198de5e8752356a5a666132211a500ea38af0fc2a0356
> ~ $ docker start cassandra3
> cassandra3
> ~ $ docker exec -ti cassandra3 bash
> {code}
> * Inside the docker container, try the default cqlsh version, make sure
> everything is working correctly
> {code:java}
> root@5d903e48e066:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> system_traces system_schema system_auth system system_distributed
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> resource_role_permissons_index role_permissions role_members roles
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> {code}
> * Okay, everything worked as expected. Now install {{git}} to clone the
> Cassandra 4.0 RC1 source code, and {{python3-six}}, which is a dependency of
> cqlsh
> {code:java}
> root@5d903e48e066:/# apt-get update -qq && apt-get install -qq git python3-six
> .. [truncated]
> {code}
> * Clone the Cassandra repository and checkout the cassandra-4.0-rc1 tag
> {code:java}
> root@5d903e48e066:/# git clone -b cassandra-4.0-rc1 --depth 1
> https://github.com/apache/cassandra.git cassandra-4.0-rc1
> Cloning into 'cassandra-4.0-rc1'...
> .. [truncated]
> {code}
> * Run the cqlsh from the Git repository, and then repeat all the cqlsh
> statements above
> {code:java}
> root@5d903e48e066:/# cd cassandra-4.0-rc1/bin
> root@5d903e48e066:/cassandra-4.0-rc1/bin# ./cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> root@5d903e48e066:/cassandra-4.0-rc1/bin#
> {code}
> "desc" did not work correctly, but "use" and "select" worked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: Revert "Fix cqlsh DESC TYPE with non-ascii character in the identifier"
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-4.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-4.0 by this push:
new a3db118 Revert "Fix cqlsh DESC TYPE with non-ascii character in the
identifier"
a3db118 is described below
commit a3db11831a0a7dd53c69da8df93bb9c35bc43eca
Author: Brandon Williams
AuthorDate: Wed May 5 07:21:53 2021 -0500
Revert "Fix cqlsh DESC TYPE with non-ascii character in the identifier"
This reverts commit 327d7c18033290f5494a6d10257735d80b8cbf29.
---
CHANGES.txt | 1 -
bin/cqlsh.py | 18 +++---
pylib/cqlshlib/copyutil.py | 2 +-
pylib/cqlshlib/test/test_cqlsh_completion.py | 5 +++-
pylib/cqlshlib/test/test_unicode.py | 35 +---
5 files changed, 16 insertions(+), 45 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index f2b0d3d..2693388 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,4 @@
4.0-rc2
- * Fix cqlsh DESC TYPE with non-ascii character in the identifier
(CASSANDRA-16400)
* Fix cqlsh encoding error with unicode in multi-line statement
(CASSANDRA-16539)
* Fix race in fat client removal (CASSANDRA-16238)
* Test org.apache.cassandra.net.AsyncPromiseTest FAILED (CASSANDRA-16596)
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 102a416..f964fc9 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -622,37 +622,37 @@ class Shell(cmd.Cmd):
self.connection_versions = vers
def get_keyspace_names(self):
-return list(self.conn.metadata.keyspaces)
+return list(map(str, list(self.conn.metadata.keyspaces.keys(
def get_columnfamily_names(self, ksname=None):
if ksname is None:
ksname = self.current_keyspace
-return list(self.get_keyspace_meta(ksname).tables)
+return list(map(str,
list(self.get_keyspace_meta(ksname).tables.keys(
def get_materialized_view_names(self, ksname=None):
if ksname is None:
ksname = self.current_keyspace
-return list(self.get_keyspace_meta(ksname).views)
+return list(map(str,
list(self.get_keyspace_meta(ksname).views.keys(
def get_index_names(self, ksname=None):
if ksname is None:
ksname = self.current_keyspace
-return list(self.get_keyspace_meta(ksname).indexes)
+return list(map(str,
list(self.get_keyspace_meta(ksname).indexes.keys(
def get_column_names(self, ksname, cfname):
if ksname is None:
ksname = self.current_keyspace
layout = self.get_table_meta(ksname, cfname)
-return list(layout.columns)
+return [str(col) for col in layout.columns]
def get_usertype_names(self, ksname=None):
if ksname is None:
ksname = self.current_keyspace
-return list(self.get_keyspace_meta(ksname).user_types)
+return list(self.get_keyspace_meta(ksname).user_types.keys())
def get_usertype_layout(self, ksname, typename):
if ksname is None:
@@ -1404,7 +1404,9 @@ class Shell(cmd.Cmd):
"""
Print the output for a DESCRIBE KEYSPACES query
"""
-names = [ensure_str(r['name']) for r in rows]
+names = list()
+for row in rows:
+names.append(str(row['name']))
print('')
cmd.Cmd.columnize(self, names)
@@ -1424,7 +1426,7 @@ class Shell(cmd.Cmd):
keyspace = row['keyspace_name']
names = list()
-names.append(ensure_str(row['name']))
+names.append(str(row['name']))
if keyspace is not None:
self.print_keyspace_element_names(keyspace, names)
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index d22bf8b..1056c52 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -560,7 +560,7 @@ class ExportWriter(object):
if self.header:
writer = csv.writer(self.current_dest.output,
**self.options.dialect)
-writer.writerow([ensure_str(c) for c in self.columns])
+writer.writerow(self.columns)
return True
diff --git a/pylib/cqlshlib/test/test_cqlsh_completion.py
b/pylib/cqlshlib/test/test_cqlsh_completion.py
index c898cbe..8b296b8 100644
--- a/pylib/cqlshlib/test/test_cqlsh_completion.py
+++ b/pylib/cqlshlib/test/test_cqlsh_completion.py
@@ -696,7 +696,10 @@ class TestCqlshCompletion(CqlshCompletionCase):
self.trycompletions('CREATE TA', immediate='BLE ')
self.create_columnfamily_table_template('TABLE')
-def test_complete_in_describe(self): # Cassandra-10733
+def test_complete_in_describe(self):
+"""
+Tests for Cassandra-10733
+"""
self.trycompletions('DES', immediate='C')
#
[cassandra] branch trunk updated (930e9a1 -> 642e95a)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 930e9a1 Merge branch 'cassandra-4.0' into trunk new a3db118 Revert "Fix cqlsh DESC TYPE with non-ascii character in the identifier" new 642e95a Merge branch 'cassandra-4.0' into trunk The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt | 1 - bin/cqlsh.py | 18 +++--- pylib/cqlshlib/copyutil.py | 2 +- pylib/cqlshlib/test/test_cqlsh_completion.py | 5 +++- pylib/cqlshlib/test/test_unicode.py | 35 +--- 5 files changed, 16 insertions(+), 45 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 642e95a4a80e2ce43272e8fa8a02306ad7a267b8 Merge: 930e9a1 a3db118 Author: Brandon Williams AuthorDate: Wed May 5 07:22:36 2021 -0500 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 - bin/cqlsh.py | 18 +++--- pylib/cqlshlib/copyutil.py | 2 +- pylib/cqlshlib/test/test_cqlsh_completion.py | 5 +++- pylib/cqlshlib/test/test_unicode.py | 35 +--- 5 files changed, 16 insertions(+), 45 deletions(-) diff --cc CHANGES.txt index 17a13b5,2693388..923dd7f --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,7 -1,4 +1,6 @@@ -4.0-rc2 +4.1 + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: - * Fix cqlsh DESC TYPE with non-ascii character in the identifier (CASSANDRA-16400) * Fix cqlsh encoding error with unicode in multi-line statement (CASSANDRA-16539) * Fix race in fat client removal (CASSANDRA-16238) * Test org.apache.cassandra.net.AsyncPromiseTest FAILED (CASSANDRA-16596) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16627:
---
Status: Ready to Commit (was: Review In Progress)
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339627#comment-17339627
]
Ekaterina Dimitrova commented on CASSANDRA-16644:
-
I played with the new multiplexer yesterday, added some debug messages but my
first try of 1000 runs didn't fail even once. I tried both java 8 and java 11.
Started another run with more repetitions but it fails as the build is failing
for some reason.
I will check again later today when the build is fixed
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339613#comment-17339613
]
Benjamin Lerer edited comment on CASSANDRA-16627 at 5/5/21, 11:54 AM:
--
+1. Thanks for the patch :-)
was (Author: blerer):
+1. Thanks for tha patch :-)
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339613#comment-17339613
]
Benjamin Lerer commented on CASSANDRA-16627:
+1. Thanks for tha patch :-)
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16653) Multinode counters don't get updated
[
https://issues.apache.org/jira/browse/CASSANDRA-16653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-16653:
-
Assignee: Andres de la Peña
> Multinode counters don't get updated
>
>
> Key: CASSANDRA-16653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16653
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Counters
>Reporter: Berenguer Blasi
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc, 4.x
>
>
> A multi node setup with counters doesn't update counters value. Works as
> expected on a single node though. Comes from
> [this|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/cql_tests.py#L460]
> test. Repro:
> {noformat}
> ccm create counters40
> ccm populate -n 2
> ccm start
> ccm node1 cqlsh
> CREATE KEYSPACE foo WITH REPLICATION = { 'class' :
> 'NetworkTopologyStrategy', 'datacenter1' : 1 } ;
> use foo;
> CREATE TABLE clicks ( userid int, url text, total counter, PRIMARY KEY
> (userid, url) ) WITH COMPACT STORAGE;
> ALTER TABLE clicks DROP COMPACT STORAGE;
> TRUNCATE clicks;
> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1
> UPDATE clicks SET total = total - 4 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1 *** Should be '-3'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339589#comment-17339589
]
Michael Semb Wever edited comment on CASSANDRA-16655 at 5/5/21, 10:51 AM:
--
bq. I amended versions bc the cqlsh tests on circle where only added to the 4.0
line.
Correct, 3.11 and older still have the `exit 0` last line:
https://github.com/apache/cassandra/blob/cassandra-3.11/pylib/cassandra-cqlsh-tests.sh#L123
But `4.0-rc2` isn't to be used until the issue is resolved. (It should be
`4.0-rc` or `4.0.x` up until that.)
was (Author: michaelsembwever):
bq. I amended versions bc the cqlsh tests on circle where only added to the 4.0
line.
Correct, 3.11 and older still have the `exit 0` last line:
https://github.com/apache/cassandra/blob/cassandra-3.11/pylib/cassandra-cqlsh-tests.sh#L123
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339589#comment-17339589
]
Michael Semb Wever commented on CASSANDRA-16655:
bq. I amended versions bc the cqlsh tests on circle where only added to the 4.0
line.
Correct, 3.11 and older still have the `exit 0` last line:
https://github.com/apache/cassandra/blob/cassandra-3.11/pylib/cassandra-cqlsh-tests.sh#L123
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16121) Circleci should run cqlshlib tests as well
[ https://issues.apache.org/jira/browse/CASSANDRA-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16121: Source Control Link: https://github.com/apache/cassandra/commit/530179c7afe6e86c0bd84e5f4557345c93fcbc0a (was: ttps://github.com/apache/cassandra/commit/530179c7afe6e86c0bd84e5f4557345c93fcbc0a) > Circleci should run cqlshlib tests as well > -- > > Key: CASSANDRA-16121 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16121 > Project: Cassandra > Issue Type: Bug > Components: CI, Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: NA > > > Currently circleci is not running cqlshlib tests. This resulted in some bugs > not being caught before committing. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339587#comment-17339587
]
Berenguer Blasi commented on CASSANDRA-16655:
-
I amended versions bc the cqlsh tests on circle where only added to the 4.0
line. So we need to fix it on 4.0 and trunk only if I am not missing anything.
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16655:
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
(was: 3.0.x)
4.0-rc2
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 4.0-rc2, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16627) Flaky DirectoriesTest.testSecondaryIndexDirectories
[
https://issues.apache.org/jira/browse/CASSANDRA-16627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339584#comment-17339584
]
Berenguer Blasi commented on CASSANDRA-16627:
-
[~blerer] as per details discussed in Slack this is in final shape and CI
attached to the PRs.
> Flaky DirectoriesTest.testSecondaryIndexDirectories
> ---
>
> Key: CASSANDRA-16627
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16627
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> See failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/462/testReport/junit/org.apache.cassandra.db/DirectoriesTest/testSecondaryIndexDirectories_cdc/]
> {noformat}
> Error Message
> expected:<1619094213489> but was:<1619094213485>
> Stacktrace
> junit.framework.AssertionFailedError: expected:<1619094213489> but
> was:<1619094213485>
> at
> org.apache.cassandra.db.DirectoriesTest.testSecondaryIndexDirectories(DirectoriesTest.java:216)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16625) Add a CircleCI job to run some tests repeatedly
[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339582#comment-17339582
]
Andres de la Peña commented on CASSANDRA-16625:
---
[~bereng] that run repeats the entire {{DirectoriesTest}} suite 10K times.
Since the suite has 15 tests, the number of run tests is 150K. The env var
[{{REPEATED_UTEST_METHODS}}|https://github.com/apache/cassandra/blob/0ff4e086dfada6b63f0c7b44551e6e53b902d5b2/.circleci/config-2_1.yml#L53]
can be used to run only {{DirectoriesTest#testSecondaryIndexDirectories}}, but
I left it blank in case something in the other tests was producing the failure.
> Add a CircleCI job to run some tests repeatedly
> ---
>
> Key: CASSANDRA-16625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it could be useful to have an optional CircleCI job to run some
> specific tests n times. That way, tickets could attach CircleCI runs showing
> that the changes don't make a certain ticket flaky or, conversely, that they
> fix a flaky test. Doing this systematically should mitigate the risk of
> introducing new flaky tests, and I guess it would be more convenient and easy
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing
> this ticket on CircleCI because it's available also for non-committers, so
> assignees can run their tests before setting the tickets as ready for review.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339577#comment-17339577
]
Berenguer Blasi commented on CASSANDRA-16655:
-
The current sh returns the error code upon a test failure and circle command
presence
{noformat}
+ command -v circleci
+ exit 1
{noformat}
It returns '0' if the command is not found. I used a mock command for testing
purposes
{noformat}
+ command -v circleci2
+ exit 0
{noformat}
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16655:
Description:
Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
reports the whole run as broken instead of that specific step with failures and
an unstable (yellow) run.
It appears the reason may be
[this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
change. At that time that was necessary to make circle fail that step.
Otherwise cqlsh failures would be ignored and that step rendered green
regarless making it useless. But it has been found now this makes jenkins
report the whole run red upon a cqlsh test failure.
The solution seems to be to return different codes depending on whether we're
on jenkins or circle. [~mck] has suggested sthg along these lines:
{code}
# circleci wants non-zero exit to report failures, jenkins wants zero exit for
a unstable status
[[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
exit 0
{code}
Procedure:
- Fix the sh script
- Break a cqlsh test
- Test the test gets reported as a failure in circle
- Test the test gets reported as a failure in jenkins and that the run and step
are yellow (not red)
- Fix the test
- Both circle and jenkins report green for that step
was:
ci-cassandra.apache.org distinguishes between FAILURE as unable to run the
tests, and UNSTABLE as failed tests. A FAILURE (red) comes from a non-zero
result on the job. An UNSTABLE comes from parsing the test results.
circleci only has two states: green or red, and requires a non-zero result to
identify failed tests.
> cassandra-cqlsh-tests.sh should return different return codes on circle vs
> jenkins
> --
>
> Key: CASSANDRA-16655
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16655
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Berenguer Blasi
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Recent jenkins runs appear broken (red) bc of a cqlsh test failure. That
> reports the whole run as broken instead of that specific step with failures
> and an unstable (yellow) run.
> It appears the reason may be
> [this|https://github.com/apache/cassandra/blame/trunk/pylib/cassandra-cqlsh-tests.sh#L146]
> change. At that time that was necessary to make circle fail that step.
> Otherwise cqlsh failures would be ignored and that step rendered green
> regarless making it useless. But it has been found now this makes jenkins
> report the whole run red upon a cqlsh test failure.
> The solution seems to be to return different codes depending on whether we're
> on jenkins or circle. [~mck] has suggested sthg along these lines:
> {code}
> # circleci wants non-zero exit to report failures, jenkins wants zero exit
> for a unstable status
> [[ command -v circleci >/dev/null 2>&1 ]] && exit ${RETURN}
> exit 0
> {code}
> Procedure:
> - Fix the sh script
> - Break a cqlsh test
> - Test the test gets reported as a failure in circle
> - Test the test gets reported as a failure in jenkins and that the run and
> step are yellow (not red)
> - Fix the test
> - Both circle and jenkins report green for that step
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16655: --- Fix Version/s: 3.11.x 3.0.x > cassandra-cqlsh-tests.sh should return different return codes on circle vs > jenkins > -- > > Key: CASSANDRA-16655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16655 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Priority: Urgent > Fix For: 3.0.x, 3.11.x, 4.0-rc, 4.x > > > ci-cassandra.apache.org distinguishes between FAILURE as unable to run the > tests, and UNSTABLE as failed tests. A FAILURE (red) comes from a non-zero > result on the job. An UNSTABLE comes from parsing the test results. > circleci only has two states: green or red, and requires a non-zero result to > identify failed tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16655: --- Severity: Critical (was: Normal) > cassandra-cqlsh-tests.sh should return different return codes on circle vs > jenkins > -- > > Key: CASSANDRA-16655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16655 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Priority: Urgent > Fix For: 4.0-rc, 4.x > > > ci-cassandra.apache.org distinguishes between FAILURE as unable to run the > tests, and UNSTABLE as failed tests. A FAILURE (red) comes from a non-zero > result on the job. An UNSTABLE comes from parsing the test results. > circleci only has two states: green or red, and requires a non-zero result to > identify failed tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16655: --- Description: ci-cassandra.apache.org distinguishes between FAILURE as unable to run the tests, and UNSTABLE as failed tests. A FAILURE (red) comes from a non-zero result on the job. An UNSTABLE comes from parsing the test results. circleci only has two states: green or red, and requires a non-zero result to identify failed tests. > cassandra-cqlsh-tests.sh should return different return codes on circle vs > jenkins > -- > > Key: CASSANDRA-16655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16655 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc, 4.x > > > ci-cassandra.apache.org distinguishes between FAILURE as unable to run the > tests, and UNSTABLE as failed tests. A FAILURE (red) comes from a non-zero > result on the job. An UNSTABLE comes from parsing the test results. > circleci only has two states: green or red, and requires a non-zero result to > identify failed tests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
[ https://issues.apache.org/jira/browse/CASSANDRA-16655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16655: --- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Low Hanging Fruit Component/s: CI Discovered By: Unit Test Fix Version/s: 4.x 4.0-rc Reviewers: Michael Semb Wever Severity: Normal Status: Open (was: Triage Needed) > cassandra-cqlsh-tests.sh should return different return codes on circle vs > jenkins > -- > > Key: CASSANDRA-16655 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16655 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc, 4.x > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16655) cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins
Berenguer Blasi created CASSANDRA-16655: --- Summary: cassandra-cqlsh-tests.sh should return different return codes on circle vs jenkins Key: CASSANDRA-16655 URL: https://issues.apache.org/jira/browse/CASSANDRA-16655 Project: Cassandra Issue Type: Bug Reporter: Berenguer Blasi -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16654) Junit RepeatableRunner falky tests helper
[
https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-16654:
Test and Documentation Plan: If can be tested by trying to run
{{DirectoriesTest}} a few times i.e.
Status: Patch Available (was: In Progress)
> Junit RepeatableRunner falky tests helper
> -
>
> Key: CASSANDRA-16654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16654
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> Some flakies only fail when the full suite is ran. If it's a quick test you
> can do thousands of runs if a few seconds. Looping at the sh level is not an
> option as every loop takes a few seconds.
> As I have found this very useful I am proposing committing it
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16654) Junit RepeatableRunner falky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16654: Summary: Junit RepeatableRunner falky tests helper (was: Junit RepeatableRunner to help with falky tests) > Junit RepeatableRunner falky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339547#comment-17339547 ] Benjamin Lerer edited comment on CASSANDRA-16619 at 5/5/21, 9:18 AM: - +1 Thanks for all the hard work [~jlewandowski] was (Author: blerer): +1. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339547#comment-17339547 ] Benjamin Lerer commented on CASSANDRA-16619: +1. > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.0, 3.0.x, 3.11.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16653) Multinode counters don't get updated
[
https://issues.apache.org/jira/browse/CASSANDRA-16653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16653:
---
Fix Version/s: (was: 4.1)
(was: 4.0-rc2)
(was: 4.0)
4.x
4.0-rc
> Multinode counters don't get updated
>
>
> Key: CASSANDRA-16653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16653
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Counters
>Reporter: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc, 4.x
>
>
> A multi node setup with counters doesn't update counters value. Works as
> expected on a single node though. Comes from
> [this|https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/cql_tests.py#L460]
> test. Repro:
> {noformat}
> ccm create counters40
> ccm populate -n 2
> ccm start
> ccm node1 cqlsh
> CREATE KEYSPACE foo WITH REPLICATION = { 'class' :
> 'NetworkTopologyStrategy', 'datacenter1' : 1 } ;
> use foo;
> CREATE TABLE clicks ( userid int, url text, total counter, PRIMARY KEY
> (userid, url) ) WITH COMPACT STORAGE;
> ALTER TABLE clicks DROP COMPACT STORAGE;
> TRUNCATE clicks;
> UPDATE clicks SET total = total + 1 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1
> UPDATE clicks SET total = total - 4 WHERE userid = 1 AND url =
> 'http://foo.com';
> SELECT total FROM clicks WHERE userid = 1 AND url = 'http://foo.com';
> total
> ---
> 1 *** Should be '-3'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16648: --- Status: Review In Progress (was: Patch Available) > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.x > > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16654) Junit RepeatableRunner to help with falky tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16654: Fix Version/s: 4.1 4.0 4.0-rc2 > Junit RepeatableRunner to help with falky tests > --- > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16654) Junit RepeatableRunner to help with falky tests
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16654: Bug Category: Parent values: Code(13163) Complexity: Normal Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Junit RepeatableRunner to help with falky tests > --- > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16654) Junit RepeatableRunner to help with falky tests
Berenguer Blasi created CASSANDRA-16654: --- Summary: Junit RepeatableRunner to help with falky tests Key: CASSANDRA-16654 URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 Project: Cassandra Issue Type: Bug Components: Test/unit Reporter: Berenguer Blasi Assignee: Berenguer Blasi Some flakies only fail when the full suite is ran. If it's a quick test you can do thousands of runs if a few seconds. Looping at the sh level is not an option as every loop takes a few seconds. As I have found this very useful I am proposing committing it -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16652) "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
[
https://issues.apache.org/jira/browse/CASSANDRA-16652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339517#comment-17339517
]
Benjamin Lerer commented on CASSANDRA-16652:
Effectively {{DESCRIBE}}|{{DESC}} will not work properly because in 4.0 we
moved to server side DESCRIBE (CASSANDRA-14825) which do not exist in 3.11.
If we want to support that scenario we need to provide a fallback mechanism in
cqlsh. That basically mean re-introducing the cqlsh code that was removed in
CASSANDRA-14825.
For the record, I am not fully sure that the output will be exactly the same
and our current tests will not test that path (as they run only against the
current version)
so we will need to introduce some upgrade tests that actually test the query
that we test in {{DescribeStatementTest}}.
The other option is to not support that feature and warn the user in the
upgrade section of the NEWS.txt.
I am probably not the best one to judge of how critical is this feature.
[~clohfink], [~jolynch] as you are involved in managing big production
clusters, I would like to hear you opinion about that ticket.
> "desc" on cqlsh 6.0.0 not working with a Cassandra 3.x server
> -
>
> Key: CASSANDRA-16652
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16652
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2
>
>
> The "desc" statement on cqlsh 6.0.0 shipped with Cassandra 4.0 RC1 is not
> working correctly when it's connected to a Cassandra 3.x server.
> Steps to reproduce:
> * Ensure you have docker installed and running
> * Run the following docker commands to create and start a Cassandra 3.11
> container
> {code:java}
> ~ $ docker create --name cassandra3 cassandra:3.11.10
> 5d903e48e0661e39080198de5e8752356a5a666132211a500ea38af0fc2a0356
> ~ $ docker start cassandra3
> cassandra3
> ~ $ docker exec -ti cassandra3 bash
> {code}
> * Inside the docker container, try the default cqlsh version, make sure
> everything is working correctly
> {code:java}
> root@5d903e48e066:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> system_traces system_schema system_auth system system_distributed
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> resource_role_permissons_index role_permissions role_members roles
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> {code}
> * Okay, everything worked as expected. Now install {{git}} to clone the
> Cassandra 4.0 RC1 source code, and {{python3-six}}, which is a dependency of
> cqlsh
> {code:java}
> root@5d903e48e066:/# apt-get update -qq && apt-get install -qq git python3-six
> .. [truncated]
> {code}
> * Clone the Cassandra repository and checkout the cassandra-4.0-rc1 tag
> {code:java}
> root@5d903e48e066:/# git clone -b cassandra-4.0-rc1 --depth 1
> https://github.com/apache/cassandra.git cassandra-4.0-rc1
> Cloning into 'cassandra-4.0-rc1'...
> .. [truncated]
> {code}
> * Run the cqlsh from the Git repository, and then repeat all the cqlsh
> statements above
> {code:java}
> root@5d903e48e066:/# cd cassandra-4.0-rc1/bin
> root@5d903e48e066:/cassandra-4.0-rc1/bin# ./cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> desc keyspaces;
> cqlsh> use system_auth;
> cqlsh:system_auth> desc tables;
> cqlsh:system_auth> select * from roles;
> role | can_login | is_superuser | member_of | salted_hash
> ---+---+--+---+--
> cassandra | True | True | null |
> $2a$10$8UNyioBF41/OZfcCa2aqXOHvXiNXArBHKaUUhMyPAFKpfN8byXonm
> (1 rows)
> cqlsh:system_auth> exit
> root@5d903e48e066:/cassandra-4.0-rc1/bin#
> {code}
> "desc" did not work correctly, but "use" and "select" worked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339516#comment-17339516
]
Berenguer Blasi edited comment on CASSANDRA-16644 at 5/5/21, 8:23 AM:
--
The only failure I could track down from [~adelapena] multi run repros the
problem
We can see
[here|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest/stdout.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081400Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=e0c2ac533b07578c306d0500b9b9c618a04799610ae57e9294a0c50827bea00d]
bq. ccmlib.node.TimeoutError: 02 May 2021 00:01:09 [node4] after 90.12/90
seconds Missing: ['Starting listening for CQL clients'] not found in system.log
it hasn't found it at 00:01:09 when it was already
[present|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest_logs/1619913669551_test_move_backwards_and_cleanup%5B9-10%5D/node4.log?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081501Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=518882b8276c0aa7947db0d75e58beb67c63be95f5b5540fac1f13fa03e026b8]
at 00:00:27
bq. INFO [main] 2021-05-02 00:00:27,098 PipelineConfigurator.java:125 -
Starting listening for CQL clients on /127.0.0.4:9042 (unencrypted)...
So sthg doesn't add up somewhere indeed...
P.D.: I tracked the failure down manually and I was lucky the 2nd run was
failing as we have missing 'fail/pass' paths in this multi run.
was (Author: bereng):
The only failure I could track down from [~adelapena] multi run repros the
problem
We can see
[here|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest/stdout.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081400Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=e0c2ac533b07578c306d0500b9b9c618a04799610ae57e9294a0c50827bea00d]
bq. ccmlib.node.TimeoutError: 02 May 2021 00:01:09 [node4] after 90.12/90
seconds Missing: ['Starting listening for CQL clients'] not found in system.log
it hasn't found it on 00:01:09 when it was already
[present|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest_logs/1619913669551_test_move_backwards_and_cleanup%5B9-10%5D/node4.log?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081501Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=518882b8276c0aa7947db0d75e58beb67c63be95f5b5540fac1f13fa03e026b8]
at 00:00:27
bq. INFO [main] 2021-05-02 00:00:27,098 PipelineConfigurator.java:125 -
Starting listening for CQL clients on /127.0.0.4:9042 (unencrypted)...
So sthg doesn't add up somewhere indeed...
P.D.: I tracked the failure down manually and I was lucky the 2nd run was
failing as we have missing 'fail/pass' paths in this multi run.
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_aft
[jira] [Comment Edited] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339516#comment-17339516
]
Berenguer Blasi edited comment on CASSANDRA-16644 at 5/5/21, 8:23 AM:
--
The only failure I could track down from [~adelapena] multi run repros the
problem
We can see
[here|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest/stdout.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081400Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=e0c2ac533b07578c306d0500b9b9c618a04799610ae57e9294a0c50827bea00d]
bq. ccmlib.node.TimeoutError: 02 May 2021 00:01:09 [node4] after 90.12/90
seconds Missing: ['Starting listening for CQL clients'] not found in system.log
it hasn't found it on 00:01:09 when it was already
[present|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest_logs/1619913669551_test_move_backwards_and_cleanup%5B9-10%5D/node4.log?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081501Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=518882b8276c0aa7947db0d75e58beb67c63be95f5b5540fac1f13fa03e026b8]
at 00:00:27
bq. INFO [main] 2021-05-02 00:00:27,098 PipelineConfigurator.java:125 -
Starting listening for CQL clients on /127.0.0.4:9042 (unencrypted)...
So sthg doesn't add up somewhere indeed...
P.D.: I tracked the failure down manually and I was lucky the 2nd run was
failing as we have missing 'fail/pass' paths in this multi run.
was (Author: bereng):
The only failure I could track down from [~adelapena] multi run repros the
problem
We can see
[here|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest/stdout.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081400Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=e0c2ac533b07578c306d0500b9b9c618a04799610ae57e9294a0c50827bea00d]
bq. ccmlib.node.TimeoutError: 02 May 2021 00:01:09 [node4] after 90.12/90
seconds Missing: ['Starting listening for CQL clients'] not found in system.log
it hasn't found it on 00:01:09 when it was already present at 00:00:27
bq. INFO [main] 2021-05-02 00:00:27,098 PipelineConfigurator.java:125 -
Starting listening for CQL clients on /127.0.0.4:9042 (unencrypted)...
So sthg doesn't add up somewhere indeed...
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return
[jira] [Commented] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339516#comment-17339516
]
Berenguer Blasi commented on CASSANDRA-16644:
-
The only failure I could track down from [~adelapena] multi run repros the
problem
We can see
[here|https://circle-production-customer-artifacts.s3.amazonaws.com/picard/52e11c3bf7d0f78c41388745/608de58867e0447553dcf233-1-build/artifacts/dtest/stdout.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210505T081400Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIAJR3Q6CR467H7Z55A%2F20210505%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=e0c2ac533b07578c306d0500b9b9c618a04799610ae57e9294a0c50827bea00d]
bq. ccmlib.node.TimeoutError: 02 May 2021 00:01:09 [node4] after 90.12/90
seconds Missing: ['Starting listening for CQL clients'] not found in system.log
it hasn't found it on 00:01:09 when it was already present at 00:00:27
bq. INFO [main] 2021-05-02 00:00:27,098 PipelineConfigurator.java:125 -
Starting listening for CQL clients on /127.0.0.4:9042 (unencrypted)...
So sthg doesn't add up somewhere indeed...
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16648: --- Fix Version/s: 4.x 4.0-rc2 > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.x > > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Fix Version/s: 4.x > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0-rc, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16642) Create release branch cassandra-4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16642:
---
Fix Version/s: 4.x
> Create release branch cassandra-4.0
> ---
>
> Key: CASSANDRA-16642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16642
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-rc, 4.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code}
> git switch -c cassandra-4.0 trunk
> git push --set-upstream origin cassandra-4.0
> {code}
> 2. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 4.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 3. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> -4. Update website versions-
> (it not needed until a release is made)
> 5. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L31
> 6. Update how_to_commit documentation
> https://github.com/apache/cassandra/blob/trunk/doc/source/development/how_to_commit.rst
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16613) ProtocolVersion.V4 is still used in places in the code
[
https://issues.apache.org/jira/browse/CASSANDRA-16613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-16613:
Status: Ready to Commit (was: Review In Progress)
+1 LGTM. If I remember right, {{ViewComplexTest}} has long been flaky due to
timeouts on anything less than the XLarge plan. It would be nice if it wasn't
necessary, but raising the timeout is the most pragmatic solution so I'm fine
with it. Also +1 to changing the in-jvm dtests to use {{CURRENT}}, I can't
think of any reason that isn't the right thing to do.
> ProtocolVersion.V4 is still used in places in the code
> --
>
> Key: CASSANDRA-16613
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16613
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc2, 4.0-rc
>
>
> While working on CASSANDRA-16567, [~adelapena] observed that
> _ProtocolVersion.V4_ is used in _ViewTest_.
> I decided to do a quick grep and observed a list of places where we still
> refer to V4 and it seems at least in many of the tests that was left not
> intentionally.
> This ticket is to verify the usage of _ProtocolVersion.V4_ in the codebase
> and bump it to V5 or default version, similar to what was done in
> CASSANDRA-16567, wherever there is a need.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16613) ProtocolVersion.V4 is still used in places in the code
[ https://issues.apache.org/jira/browse/CASSANDRA-16613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16613: Reviewers: Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Sam Tunnicliffe, Sam Tunnicliffe (was: Sam Tunnicliffe) Status: Review In Progress (was: Patch Available) > ProtocolVersion.V4 is still used in places in the code > -- > > Key: CASSANDRA-16613 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16613 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc2, 4.0-rc > > > While working on CASSANDRA-16567, [~adelapena] observed that > _ProtocolVersion.V4_ is used in _ViewTest_. > I decided to do a quick grep and observed a list of places where we still > refer to V4 and it seems at least in many of the tests that was left not > intentionally. > This ticket is to verify the usage of _ProtocolVersion.V4_ in the codebase > and bump it to V5 or default version, similar to what was done in > CASSANDRA-16567, wherever there is a need. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339478#comment-17339478 ] Berenguer Blasi edited comment on CASSANDRA-16648 at 5/5/21, 7:36 AM: -- [~mck] I am putting this up for review with the following proposal: - Merge my current [PR|https://github.com/apache/cassandra-dtest/pull/134] - CASSANDRA-16653 for the remaining non obvious failure Before merging I will run 2 devbranch runs in CI against truck and 4.0 to make sure I didn't brake anything. was (Author: bereng): [~mck] I am putting this up for review with the following proposal: - Merge my current [PR|https://github.com/apache/cassandra-dtest/pull/134] - CASSANDRA-16653 for the remaining non obvious failure > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16648: Reviewers: Berenguer Blasi, Michael Semb Wever (was: Berenguer Blasi) > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16648: Authors: Berenguer Blasi, Michael Semb Wever (was: Michael Semb Wever) > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-16648: --- Assignee: Berenguer Blasi (was: Michael Semb Wever) > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Berenguer Blasi >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339478#comment-17339478 ] Berenguer Blasi edited comment on CASSANDRA-16648 at 5/5/21, 7:30 AM: -- [~mck] I am putting this up for review with the following proposal: - Merge my current [PR|https://github.com/apache/cassandra-dtest/pull/134] - CASSANDRA-16653 for the remaining non obvious failure was (Author: bereng): [~mck] I am putting this up for review with the following proposal: - Merge my current PR - CASSANDRA-16653 for the remaining non obvious failure > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17339478#comment-17339478 ] Berenguer Blasi commented on CASSANDRA-16648: - [~mck] I am putting this up for review with the following proposal: - Merge my current PR - CASSANDRA-16653 for the remaining non obvious failure > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16648) Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16648: Test and Documentation Plan: See PR Status: Patch Available (was: In Progress) > Add 4_0_x to Python DTest's upgrade_manifest (after cassandra-4.0 branch was > created) > - > > Key: CASSANDRA-16648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16648 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Python DTest upgrade manifest: > - > https://github.com/apache/cassandra-dtest/compare/trunk...thelastpickle:mck/16642--introduce-cassandra-4.0 > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest/645/ > - https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/273/ -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
