[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494882#comment-17494882 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/19/22, 3:57 AM: -- I've updated this PR with complete removal of nose, which was just used in two imports with assert_raises ([test_sslhandling.py|https://github.com/apache/cassandra/pull/1445/files#diff-057858697ae1e4bf6ce45a04be0f86db981a17626fc44c4d2236b11e46c7c572]) and @nottest ([cassconnect.py|https://github.com/apache/cassandra/pull/1445/files#diff-1b10bccb3fa32f131ec7bcc8b6b03c776e96e2176ef6431873005c3ef46abd29]) was (Author: bschoeni): I've updated this with complete removal of nose, which was just used in two imports with assert_raises ([test_sslhandling.py|https://github.com/apache/cassandra/pull/1445/files#diff-057858697ae1e4bf6ce45a04be0f86db981a17626fc44c4d2236b11e46c7c572]) and @nottest ([cassconnect.py|https://github.com/apache/cassandra/pull/1445/files#diff-1b10bccb3fa32f131ec7bcc8b6b03c776e96e2176ef6431873005c3ef46abd29]) > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494882#comment-17494882 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/19/22, 3:34 AM: -- I've updated this with complete removal of nose, which was just used in two imports with assert_raises ([test_sslhandling.py|https://github.com/apache/cassandra/pull/1445/files#diff-057858697ae1e4bf6ce45a04be0f86db981a17626fc44c4d2236b11e46c7c572]) and @nottest ([cassconnect.py|https://github.com/apache/cassandra/pull/1445/files#diff-1b10bccb3fa32f131ec7bcc8b6b03c776e96e2176ef6431873005c3ef46abd29]) was (Author: bschoeni): I've updated this with complete removal of nose, which was just two imports. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494882#comment-17494882 ] Brad Schoening commented on CASSANDRA-17293: I've updated this with complete removal of nose, which was just two imports. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening reassigned CASSANDRA-17397:
--
Assignee: Brad Schoening
> cleanup cqlshlib unit test failures and warnings
>
>
> Key: CASSANDRA-17397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17397
> Project: Cassandra
> Issue Type: Bug
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
>
> The cqlshlib unit tests have some regular failures and warnings.
> # test_copyutil.py fails with too many open files when ulimit is 256
> # nose/importer.py:12: DeprecationWarning: the imp module is deprecated in
> favour of importlib
> # cassconnect.py:39: DeprecationWarning: Legacy execution parameters
> # sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
> renamed to ConfigParser
>
> The cqlshlib test test_copyutil.py fails on MacOS with
> *E OSError: [Errno 24] Too many open files*
> This happens because the test does not close the file descriptors after use.
> The default ulimit on MacOS is small, 256:
> % ulimit -n
> 256
> The simple fix is to close the pipe after use. Increasing ulimit nofiles
> works also, but shouldn't be necessary.
>
>
> {*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
> export_task = ExportTask(shell, self.ks, self.table, self.columns,
> self.fname, overridden_opts, self.protocol_version, self.config_file)
> {*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
> CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname,
> opts, protocol_version, config_file, 'to')
> {*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
> self.inmsg = ReceivingChannels(self.num_processes)
> {*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
> self.pipes = [OneWayPipe() for _ in range(num_channels)]
> {*}copyutil.py{*}:186: in
> self.pipes = [OneWayPipe() for _ in range(num_channels)]
> {*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
> self.reader, self.writer = mp.Pipe(duplex=False)
> {*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
> in Pipe
> return Pipe(duplex)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> duplex = False
>
> def Pipe(duplex=True):
> '''
> Returns pair of connection objects at either end of a pipe
> '''
> if duplex:
> s1, s2 = socket.socketpair()
> s1.setblocking(True)
> s2.setblocking(True)
> c1 = Connection(s1.detach())
> c2 = Connection(s2.detach())
> else:
> > fd1, fd2 = os.pipe()
> *E OSError: [Errno 24] Too many open files*
>
> {*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
> OSError
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17397:
---
Description:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# nose/importer.py:12: DeprecationWarning: the imp module is deprecated in
favour of importlib
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in {_}{{_}}init{{_}}{_}
CopyTask.{_}{{_}}init{{_}}{_}(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in {_}{{_}}init{{_}}{_}
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in {_}{{_}}init{{_}}{_}
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in {_}{{_}}init{{_}}{_}
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
OSError
was:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# nose creates deprecated warnings
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in _{_}init{_}_
CopyTask._{_}init{_}_(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in _{_}init{_}_
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in _{_}init{_}_
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in _{_}init{_}_
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
>
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[
https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17397:
---
Description:
The cqlshlib unit tests have some regular failures and warnings.
# test_copyutil.py fails with too many open files when ulimit is 256
# nose creates deprecated warnings
# cassconnect.py:39: DeprecationWarning: Legacy execution parameters
# sslhandling.py:42: DeprecationWarning: The SafeConfigParser class has been
renamed to ConfigParser
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
{*}test/test_copyutil.py{*}:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
{*}copyutil.py{*}:638: in _{_}init{_}_
CopyTask._{_}init{_}_(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
{*}copyutil.py{*}:275: in _{_}init{_}_
self.inmsg = ReceivingChannels(self.num_processes)
{*}copyutil.py{*}:186: in _{_}init{_}_
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
{*}copyutil.py{*}:103: in _{_}init{_}_
self.reader, self.writer = mp.Pipe(duplex=False)
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py{*}:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
{*}/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py{*}:532:
OSError
was:
The cqlshlib test test_copyutil.py fails on MacOS with
*E OSError: [Errno 24] Too many open files*
This happens because the test does not close the file descriptors after use.
The default ulimit on MacOS is small, 256:
% ulimit -n
256
The simple fix is to close the pipe after use. Increasing ulimit nofiles works
also, but shouldn't be necessary.
*test/test_copyutil.py*:80: in _test_get_ranges_murmur3_base
export_task = ExportTask(shell, self.ks, self.table, self.columns,
self.fname, overridden_opts, self.protocol_version, self.config_file)
*copyutil.py*:638: in __init__
CopyTask.__init__(self, shell, ks, table, columns, fname, opts,
protocol_version, config_file, 'to')
*copyutil.py*:275: in __init__
self.inmsg = ReceivingChannels(self.num_processes)
*copyutil.py*:186: in __init__
self.pipes = [OneWayPipe() for _ in range(num_channels)]
*copyutil.py*:186: in
self.pipes = [OneWayPipe() for _ in range(num_channels)]
*copyutil.py*:103: in __init__
self.reader, self.writer = mp.Pipe(duplex=False)
*/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py*:63:
in Pipe
return Pipe(duplex)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
duplex = False
def Pipe(duplex=True):
'''
Returns pair of connection objects at either end of a pipe
'''
if duplex:
s1, s2 = socket.socketpair()
s1.setblocking(True)
s2.setblocking(True)
c1 = Connection(s1.detach())
c2 = Connection(s2.detach())
else:
> fd1, fd2 = os.pipe()
*E OSError: [Errno 24] Too many open files*
*/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py*:532:
OSError
> cleanup cqlshlib unit test failures and warnings
>
>
> Key: CASSANDRA-17397
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17397
> Project: Cassandra
> Issue Type: B
[jira] [Updated] (CASSANDRA-17397) cleanup cqlshlib unit test failures and warnings
[ https://issues.apache.org/jira/browse/CASSANDRA-17397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17397: --- Summary: cleanup cqlshlib unit test failures and warnings (was: cqlshlib unit test test_copyutil.py can fail due to too many open files) > cleanup cqlshlib unit test failures and warnings > > > Key: CASSANDRA-17397 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17397 > Project: Cassandra > Issue Type: Bug >Reporter: Brad Schoening >Priority: Normal > > The cqlshlib test test_copyutil.py fails on MacOS with > *E OSError: [Errno 24] Too many open files* > This happens because the test does not close the file descriptors after use. > The default ulimit on MacOS is small, 256: > % ulimit -n > 256 > The simple fix is to close the pipe after use. Increasing ulimit nofiles > works also, but shouldn't be necessary. > > > *test/test_copyutil.py*:80: in _test_get_ranges_murmur3_base > export_task = ExportTask(shell, self.ks, self.table, self.columns, > self.fname, overridden_opts, self.protocol_version, self.config_file) > *copyutil.py*:638: in __init__ > CopyTask.__init__(self, shell, ks, table, columns, fname, opts, > protocol_version, config_file, 'to') > *copyutil.py*:275: in __init__ > self.inmsg = ReceivingChannels(self.num_processes) > *copyutil.py*:186: in __init__ > self.pipes = [OneWayPipe() for _ in range(num_channels)] > *copyutil.py*:186: in > self.pipes = [OneWayPipe() for _ in range(num_channels)] > *copyutil.py*:103: in __init__ > self.reader, self.writer = mp.Pipe(duplex=False) > */usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py*:63: > in Pipe > return Pipe(duplex) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > duplex = False > > def Pipe(duplex=True): > ''' > Returns pair of connection objects at either end of a pipe > ''' > if duplex: > s1, s2 = socket.socketpair() > s1.setblocking(True) > s2.setblocking(True) > c1 = Connection(s1.detach()) > c2 = Connection(s2.detach()) > else: > > fd1, fd2 = os.pipe() > *E OSError: [Errno 24] Too many open files* > > */usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py*:532: > OSError -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17397) cqlshlib unit test test_copyutil.py can fail due to too many open files
Brad Schoening created CASSANDRA-17397: -- Summary: cqlshlib unit test test_copyutil.py can fail due to too many open files Key: CASSANDRA-17397 URL: https://issues.apache.org/jira/browse/CASSANDRA-17397 Project: Cassandra Issue Type: Bug Reporter: Brad Schoening The cqlshlib test test_copyutil.py fails on MacOS with *E OSError: [Errno 24] Too many open files* This happens because the test does not close the file descriptors after use. The default ulimit on MacOS is small, 256: % ulimit -n 256 The simple fix is to close the pipe after use. Increasing ulimit nofiles works also, but shouldn't be necessary. *test/test_copyutil.py*:80: in _test_get_ranges_murmur3_base export_task = ExportTask(shell, self.ks, self.table, self.columns, self.fname, overridden_opts, self.protocol_version, self.config_file) *copyutil.py*:638: in __init__ CopyTask.__init__(self, shell, ks, table, columns, fname, opts, protocol_version, config_file, 'to') *copyutil.py*:275: in __init__ self.inmsg = ReceivingChannels(self.num_processes) *copyutil.py*:186: in __init__ self.pipes = [OneWayPipe() for _ in range(num_channels)] *copyutil.py*:186: in self.pipes = [OneWayPipe() for _ in range(num_channels)] *copyutil.py*:103: in __init__ self.reader, self.writer = mp.Pipe(duplex=False) */usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/context.py*:63: in Pipe return Pipe(duplex) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ duplex = False def Pipe(duplex=True): ''' Returns pair of connection objects at either end of a pipe ''' if duplex: s1, s2 = socket.socketpair() s1.setblocking(True) s2.setblocking(True) c1 = Connection(s1.detach()) c2 = Connection(s2.detach()) else: > fd1, fd2 = os.pipe() *E OSError: [Errno 24] Too many open files* */usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/connection.py*:532: OSError -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494850#comment-17494850 ] Brian Houser commented on CASSANDRA-16456: -- Sorry about the delay in update. I have truly started the work and will be adding more consistent updates in the future. Working on this exclusively in the next couple of weeks. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: ninja-fix CHANGES.txt so >4.0.0 entries are "Merged in …" entries
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 The following commit(s) were added to refs/heads/trunk by this push: new c08baf2 ninja-fix CHANGES.txt so >4.0.0 entries are "Merged in …" entries c08baf2 is described below commit c08baf20c67cb16eeac00f2bcb23dd87384e7701 Author: Mick Semb Wever AuthorDate: Sat Feb 19 00:07:39 2022 +0100 ninja-fix CHANGES.txt so >4.0.0 entries are "Merged in …" entries --- CHANGES.txt | 56 +++- 1 file changed, 23 insertions(+), 33 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 25a472b..9bbb57e 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -90,17 +90,10 @@ * Add a system property to set hostId if not yet initialized (CASSANDRA-14582) * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) * Update JNA library to 5.9.0 and snappy-java to version 1.1.8.4 (CASSANDRA-17040) -Merged from 3.0: - * Fixed TestCqlshOutput failing tests (CASSANDRA-17386) - * Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction (CASSANDRA-17273) - * LeveledCompactionStrategy disk space check improvements (CASSANDRA-17272) - -4.0.3 +Merged from 4.0: * Deprecate otc_coalescing_strategy, otc_coalescing_window_us, otc_coalescing_enough_coalesced_messages, otc_backlog_expiration_interval_ms (CASSANDRA-17377) * Improve start up processing of Incremental Repair information read from system.repairs (CASSANDRA-17342) - -4.0.2 * Extend operator control over the UDF threading model for CVE-2021-44521 (CASSANDRA-17352) * Full Java 11 support (CASSANDRA-16894) * Remove unused 'geomet' package from cqlsh path (CASSANDRA-17271) @@ -129,11 +122,33 @@ Merged from 3.0: * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) + * Tolerate missing DNS entry when completing a host replacement (CASSANDRA-16873) + * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) + * Move RepairedDataInfo to the execution controller rather than the ReadCommand to avoid unintended sharing (CASSANDRA-16721) + * Bump zstd-jni version to 1.5.0-4 (CASSANDRA-16884) + * Remove assumption that all urgent messages are small (CASSANDRA-16877) + * ArrayClustering.unsharedHeapSize does not include the data so undercounts the heap size (CASSANDRA-16845) + * Improve help, doc and error messages about sstabledump -k and -x arguments (CASSANDRA-16818) + * Add repaired/unrepaired bytes back to nodetool (CASSANDRA-15282) + * Upgrade lz4-java to 1.8.0 to add RH6 support back (CASSANDRA-16753) + * Improve DiagnosticEventService.publish(event) logging message of events (CASSANDRA-16749) + * Cleanup dependency scopes (CASSANDRA-16704) + * Make JmxHistogram#getRecentValues() and JmxTimer#getRecentValues() thread-safe (CASSANDRA-16707) Merged from 3.11: * Add key validation to ssstablescrub (CASSANDRA-16969) * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851) * Make assassinate more resilient to missing tokens (CASSANDRA-16847) + * Validate SASI tokenizer options before adding index to schema (CASSANDRA-15135) + * Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition (CASSANDRA-16835) + * Reduce thread contention in CommitLogSegment and HintsBuffer (CASSANDRA-16072) + * Make cqlsh use the same set of reserved keywords than the server uses (CASSANDRA-15663) + * Optimize bytes skipping when reading SSTable files (CASSANDRA-14415) + * Enable tombstone compactions when unchecked_tombstone_compaction is set in TWCS (CASSANDRA-14496) + * Read only the required SSTables for single partition queries (CASSANDRA-16737) Merged from 3.0: + * Fixed TestCqlshOutput failing tests (CASSANDRA-17386) + * Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction (CASSANDRA-17273) + * LeveledCompactionStrategy disk space check improvements (CASSANDRA-17272) * Fix conversion from megabits to bytes in streaming rate limiter (CASSANDRA-17243) * Upgrade logback to 1.2.9 (CASSANDRA-17204) * Avoid race in AbstractReplicationStrategy endpoint caching (CASSANDRA-16673) @@ -154,29 +169,6 @@ Merged from 3.0: * Catch UnsatisfiedLinkError in WindowsTimer (CASSANDRA-16085) * Avoid removing batch when it's not created during view replication (CASSANDRA-16175) * Make the addition of regular column to COMPACT tables throw an InvalidRequestException (CASSANDRA-14564) - -4.0.1 - * Tolerate missing DNS entry when completing a host replacement
[jira] [Commented] (CASSANDRA-14797) CQLSSTableWriter does not support DELETE
[
https://issues.apache.org/jira/browse/CASSANDRA-14797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494838#comment-17494838
]
Doug Rohrer commented on CASSANDRA-14797:
-
PR in https://github.com/apache/cassandra/pull/1461 against trunk to get Circle
running.
> CQLSSTableWriter does not support DELETE
>
>
> Key: CASSANDRA-14797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14797
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Eric Evans
>Priority: Low
> Fix For: 3.11.x, 4.x
>
>
> {{CQLSSTableWriter}} doesn't work with {{DELETE}} statements, and ought to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (ccac41f -> e31295c)
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard ccac41f generate docs for e98ea999
add c813553 CASSANDRA-17394 Upgrade Advisory: 3.0, 3.11, 4.0 Possible for
Remote Code Execution for Scripted UDFs patch by Diogenese Topper; reviewed by
PMC for CASSANDRA-17394
add e31295c generate docs for c8135531
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (ccac41f)
\
N -- N -- N refs/heads/asf-site (e31295c)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
content/_/blog.html| 28 +-
...pgrade-Advisory.html => Upgrade-Advisory2.html} | 41 -
content/search-index.js| 2 +-
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
.../modules/ROOT/pages/blog/Upgrade-Advisory2.adoc | 25 +
site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084
bytes
6 files changed, 100 insertions(+), 21 deletions(-)
copy content/_/blog/{Upgrade-Advisory.html => Upgrade-Advisory2.html} (84%)
create mode 100644
site-content/source/modules/ROOT/pages/blog/Upgrade-Advisory2.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (ccac41f -> e31295c)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
omit ccac41f generate docs for e98ea999
add c813553 CASSANDRA-17394 Upgrade Advisory: 3.0, 3.11, 4.0 Possible for
Remote Code Execution for Scripted UDFs patch by Diogenese Topper; reviewed by
PMC for CASSANDRA-17394
new e31295c generate docs for c8135531
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (ccac41f)
\
N -- N -- N refs/heads/asf-staging (e31295c)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 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:
content/_/blog.html| 28 +-
...pgrade-Advisory.html => Upgrade-Advisory2.html} | 41 -
content/search-index.js| 2 +-
site-content/source/modules/ROOT/pages/blog.adoc | 25 +
.../modules/ROOT/pages/blog/Upgrade-Advisory2.adoc | 25 +
site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084
bytes
6 files changed, 100 insertions(+), 21 deletions(-)
copy content/_/blog/{Upgrade-Advisory.html => Upgrade-Advisory2.html} (84%)
create mode 100644
site-content/source/modules/ROOT/pages/blog/Upgrade-Advisory2.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) BLOG - Make minor corrections "Tightening Security part 3"
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17396: -- Description: We released a blog entry as part of https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the need for a minor correction in it. This ticket is for the correction. Blog post - [Tightening security for Apache Cassandra: Part 3|http://example.com|https://cassandra.apache.org/_/blog/Tightening-Security-for-Apache-Cassandra-Part-3.html] was: We released a blog entry as part of https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the need for a minor correction in it. This ticket is for the correction. > BLOG - Make minor corrections "Tightening Security part 3" > -- > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Blog >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the > need for a minor correction in it. > This ticket is for the correction. > Blog post - [Tightening security for Apache Cassandra: Part > 3|http://example.com|https://cassandra.apache.org/_/blog/Tightening-Security-for-Apache-Cassandra-Part-3.html] -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) BLOG - Make minor corrections "Tightening Security part 3"
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17396: -- Summary: BLOG - Make minor corrections "Tightening Security part 3" (was: WEBSITE - Minor corrections on a released public blog) > BLOG - Make minor corrections "Tightening Security part 3" > -- > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Blog >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17396: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Website Fix Version/s: 4.0.x Reviewers: Erick Ramirez Status: Open (was: Triage Needed) > WEBSITE - Minor corrections on a released public blog > - > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maulin Vasavada updated CASSANDRA-17396: Description: We released a blog entry as part of https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the need for a minor correction in it. This ticket is for the correction. was: We released a blog entry as part of https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized a need for a minor correction in it. This ticket is for the correction. > WEBSITE - Minor corrections on a released public blog > - > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17396: -- Component/s: Documentation/Blog (was: Documentation/Website) > WEBSITE - Minor corrections on a released public blog > - > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Blog >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized the > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494822#comment-17494822
]
Brandon Williams commented on CASSANDRA-17367:
--
4.0:
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/372/workflows/79d13c71-76b0-4145-9871-bb9d47ee2ab2],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/372/workflows/12c899f4-0396-4c8b-bb3f-f35fc97f6b06]
trunk:
[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/373/workflows/06936965-722e-43df-9a7b-7c17ff04a468],
[j11|https://app.circleci.com/pipelines/github/driftx/cassandra/373/workflows/9d2fc929-37d5-4f77-b08a-ab1318e6ebc2]
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494820#comment-17494820 ] Maulin Vasavada commented on CASSANDRA-17396: - Pull request: [PR#103|https://github.com/apache/cassandra-website/pull/103] > WEBSITE - Minor corrections on a released public blog > - > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized a > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
[ https://issues.apache.org/jira/browse/CASSANDRA-17396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17396: --- Labels: pull-request-available (was: ) > WEBSITE - Minor corrections on a released public blog > - > > Key: CASSANDRA-17396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 > Project: Cassandra > Issue Type: Improvement >Reporter: Maulin Vasavada >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > > We released a blog entry as part of > https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized a > need for a minor correction in it. > This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17396) WEBSITE - Minor corrections on a released public blog
Maulin Vasavada created CASSANDRA-17396: --- Summary: WEBSITE - Minor corrections on a released public blog Key: CASSANDRA-17396 URL: https://issues.apache.org/jira/browse/CASSANDRA-17396 Project: Cassandra Issue Type: Improvement Reporter: Maulin Vasavada Assignee: Erick Ramirez We released a blog entry as part of https://issues.apache.org/jira/browse/CASSANDRA-17373 However we realized a need for a minor correction in it. This ticket is for the correction. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: CASSANDRA-17394 Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs patch by Diogenese Topper; reviewed by PMC for CASSANDRA
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new c813553 CASSANDRA-17394 Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs patch by Diogenese Topper; reviewed by PMC for CASSANDRA-17394 c813553 is described below commit c8135531e97d9f0de4fc39437c6c18e18e6e4f79 Author: Diogenese Topper AuthorDate: Fri Feb 18 11:30:00 2022 -0800 CASSANDRA-17394 Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs patch by Diogenese Topper; reviewed by PMC for CASSANDRA-17394 --- site-content/source/modules/ROOT/pages/blog.adoc | 25 ++ .../modules/ROOT/pages/blog/Upgrade-Advisory2.adoc | 25 ++ 2 files changed, 50 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index 946af0f..14e51cd 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -14,6 +14,31 @@ NOTES FOR CONTENT CREATORS [openblock,card-header] -- [discrete] +=== Apache Cassandra Upgrade Advisory +[discrete] + February 18, 2022 +-- +[openblock,card-content] +-- +If the operator has configured the cluster in a documented insecure way, it is possible for malicious users to execute remote code using scripted UDFs. Users of Apache Cassandra 3.0, 3.11, and 4.0 to upgrade or to reset enable_user_defined_functions_threads back to true. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Upgrade-Advisory2.adoc[Read More] + + +-- + +//end card + +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] === Behind the scenes of an Apache Cassandra Release [discrete] February 18, 2022 diff --git a/site-content/source/modules/ROOT/pages/blog/Upgrade-Advisory2.adoc b/site-content/source/modules/ROOT/pages/blog/Upgrade-Advisory2.adoc new file mode 100644 index 000..c4353be --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Upgrade-Advisory2.adoc @@ -0,0 +1,25 @@ += Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs +:page-layout: single-post +:page-role: blog-post +:page-post-date: February 18, 2022 +:page-post-author: The Apache Cassandra Community +:description: The Apache Cassandra Community +:keywords: + +If the operator has configured the cluster in a documented insecure way, it is possible for a malicious user to execute remote code using scripted UDFs. We are advising users of Apache Cassandra 3.0, 3.11 and 4.0 to upgrade or to reset enable_user_defined_functions_threads back to true. + +The vulnerability being tracked in CASSANDRA-17352 makes it possible for an attacker to execute arbitrary code on the host. It’s important to note that to be exposed the user would have to opt-in to a configuration option that is documented as unsafe in the configuration file. While it’s difficult to estimate exposure to this CVE, it is likely narrow due to the need for opt-in. Note that this configuration is documented as unsafe, and will continue to be considered unsafe after this CVE. + +Mitigation: + +1. When running Apache Cassandra with the following configuration: +``` +enable_user_defined_functions: true +enable_scripted_user_defined_functions: true +enable_user_defined_functions_threads: false +``` + +Set `enable_user_defined_functions_threads: true` (this is default) + +[start=2] +2. We suggest 3.0 users should upgrade to 3.0.26; 3.11 users should upgrade to 3.11.12; and 4.0 users should upgrade to 4.0.3. \ No newline at end of file - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17395) WEBSITE - February homepage update and blog fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17395: - Description: This ticket is to capture the work associated with updating the Apache Cassandra homepage and a few edits to blog posts to fix incorrect dates and text. (was: This ticket is to capture the work associated with updating the Apache Cassandra homepage and a few edits to blog posts to fix incorrect dates/links/etc.) > WEBSITE - February homepage update and blog fixes > - > > Key: CASSANDRA-17395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updating the Apache > Cassandra homepage and a few edits to blog posts to fix incorrect dates and > text. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17395) WEBSITE - February homepage update and blog fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17395: - Authors: Chris Thornett, Diogenese Topper Change Category: Semantic Complexity: Normal Impacts: Docs (was: None) Test and Documentation Plan: Update homepage for * Cassandra 4.0 blog post text * Cassandra Users quote * Community spotlight links, text, and images * Hyperlinks on images Blog post updates include: * "Apache Cassandra 4.0 is Here" date change * "Behind the scenes of an Apache Cassandra Release" text correction > WEBSITE - February homepage update and blog fixes > - > > Key: CASSANDRA-17395 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > > This ticket is to capture the work associated with updating the Apache > Cassandra homepage and a few edits to blog posts to fix incorrect > dates/links/etc. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17395) WEBSITE - February homepage update and blog fixes
Diogenese Topper created CASSANDRA-17395: Summary: WEBSITE - February homepage update and blog fixes Key: CASSANDRA-17395 URL: https://issues.apache.org/jira/browse/CASSANDRA-17395 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with updating the Apache Cassandra homepage and a few edits to blog posts to fix incorrect dates/links/etc. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16349) SSTableLoader reports error when SSTable(s) do not have data for some nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494816#comment-17494816
]
Ekaterina Dimitrova edited comment on CASSANDRA-16349 at 2/18/22, 8:43 PM:
---
[~blerer] is not available these days, I pinged in Slack [~jasonstack] to ask
if he might have a bit of time to check it but we are in totally different time
zones so I haven't received a response yet. I promise to follow up no this work
next week
was (Author: e.dimitrova):
[~blerer] is not available these days, I pinged in Slack [~jasonstack] to ask
if he might have a bit of time to check it but we are in totally different time
zones so I haven't received a response yet. I promise to follow up next week
> SSTableLoader reports error when SSTable(s) do not have data for some nodes
> ---
>
> Key: CASSANDRA-16349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16349
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running SSTableLoader in verbose mode will show error(s) if there are node(s)
> that do not own any data from the SSTable(s). This can happen in at least 2
> cases:
> # SSTableLoader is used to stream backups while keeping the same token ranges
> # SSTable(s) are created with CQLSSTableWriter to match token ranges (this
> can bring better performance by using ZeroCopy streaming)
> Partial output of the SSTableLoader:
> {quote}ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47]
> Remote peer /127.0.0.4:7000 failed stream session.
> ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47] Remote peer
> /127.0.0.3:7000 failed stream session.
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.515KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.427KiB/s)
> {quote}
>
> Stack trace:
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:533)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:99)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:88)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1056)
> at
> com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138)
> at
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:748)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:220)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:196)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:505)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:819)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:595)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {quote}
> To reproduce create a cluster with ccm with more nodes than the RF, put some
> data into it copy a SSTable and stream it.
>
> The error originates on the nodes, the following stack trace is shown in the
> logs:
> {quote}java.lang.IllegalStateException: Stream hasn't been read yet
> at
> com.google.common.base.Prec
[jira] [Commented] (CASSANDRA-16349) SSTableLoader reports error when SSTable(s) do not have data for some nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494816#comment-17494816
]
Ekaterina Dimitrova commented on CASSANDRA-16349:
-
[~blerer] is not available these days, I pinged in Slack [~jasonstack] to ask
if he might have a bit of time to check it but we are in totally different time
zones so I haven't received a response yet. I promise to follow up next week
> SSTableLoader reports error when SSTable(s) do not have data for some nodes
> ---
>
> Key: CASSANDRA-16349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16349
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running SSTableLoader in verbose mode will show error(s) if there are node(s)
> that do not own any data from the SSTable(s). This can happen in at least 2
> cases:
> # SSTableLoader is used to stream backups while keeping the same token ranges
> # SSTable(s) are created with CQLSSTableWriter to match token ranges (this
> can bring better performance by using ZeroCopy streaming)
> Partial output of the SSTableLoader:
> {quote}ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47]
> Remote peer /127.0.0.4:7000 failed stream session.
> ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47] Remote peer
> /127.0.0.3:7000 failed stream session.
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.515KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.427KiB/s)
> {quote}
>
> Stack trace:
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:533)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:99)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:88)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1056)
> at
> com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138)
> at
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:748)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:220)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:196)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:505)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:819)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:595)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {quote}
> To reproduce create a cluster with ccm with more nodes than the RF, put some
> data into it copy a SSTable and stream it.
>
> The error originates on the nodes, the following stack trace is shown in the
> logs:
> {quote}java.lang.IllegalStateException: Stream hasn't been read yet
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:507)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:789)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(Strea
[jira] [Commented] (CASSANDRA-16878) Race in commit log replay can cause rejected mutations
[ https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494810#comment-17494810 ] Yifan Cai commented on CASSANDRA-16878: --- Again, you are right :D The related mutations and the schema change (i.e. persist and update in-memory) needs to be linearized. The related mutations are the ones contain updates to the changed schema. Before applying the schema change, it creates a barrier and waits for all related pending mutations to complete. No related mutations arriving after the barrier can be created until the schema change completes. Maybe use a readwrite lock to implement. It could result into write timeouts during schema change. Alternatively, maybe we can reorder the mutations when replaying. But it would require to serialize the schema version, and change the commit log format. Group the mutations belongs to the same schema version and replay each group. > Race in commit log replay can cause rejected mutations > -- > > Key: CASSANDRA-16878 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16878 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Andres de la Peña >Assignee: Andres de la Peña >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 10m > Remaining Estimate: 0h > > We don't force order in the execution of replayed mutations and hence a > mutation can move ahead of or behind a schema change it relies on (e.g. > added/removed column), which can then cause it to be rejected because of a > schema mismatch. > To fix this, we need to identify schema mutations and make sure the log > enforces their execution after all previous mutations have completed and > before anything following is started. > Schema mutations are > [flushed|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271] > after being applied, so this only would be a problem if the node abruptly > stops before flushing the schema mutation. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17394) WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs"
[ https://issues.apache.org/jira/browse/CASSANDRA-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17394: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/102 > WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for > Remote Code Execution for Scripted UDFs" > > > Key: CASSANDRA-17394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17394 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Urgent > Labels: pull-request-available > Fix For: 3.0.0, 3.0.11, 4.0 > > > This ticket is to capture the work associated with publishing the February > 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code > Execution for Scripted UDFs" > If this blog cannot be published by the *February 18, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17394) WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs"
[ https://issues.apache.org/jira/browse/CASSANDRA-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17394: --- Labels: pull-request-available (was: ) > WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for > Remote Code Execution for Scripted UDFs" > > > Key: CASSANDRA-17394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17394 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Urgent > Labels: pull-request-available > Fix For: 3.0.0, 3.0.11, 4.0 > > > This ticket is to capture the work associated with publishing the February > 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code > Execution for Scripted UDFs" > If this blog cannot be published by the *February 18, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17394) WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs"
[ https://issues.apache.org/jira/browse/CASSANDRA-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17394: - Status: Open (was: Triage Needed) > WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for > Remote Code Execution for Scripted UDFs" > > > Key: CASSANDRA-17394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17394 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Urgent > Labels: pull-request-available > Fix For: 4.0, 3.0.11, 3.0.0 > > > This ticket is to capture the work associated with publishing the February > 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code > Execution for Scripted UDFs" > If this blog cannot be published by the *February 18, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17394) WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs"
[ https://issues.apache.org/jira/browse/CASSANDRA-17394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17394: - Change Category: Semantic Complexity: Normal Fix Version/s: 4.0 3.0.11 3.0.0 Impacts: Docs (was: None) Test and Documentation Plan: * Add blog post titled "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs" * Update blog index Priority: Urgent (was: Normal) > WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for > Remote Code Execution for Scripted UDFs" > > > Key: CASSANDRA-17394 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17394 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Urgent > Fix For: 3.0.0, 3.0.11, 4.0 > > > This ticket is to capture the work associated with publishing the February > 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code > Execution for Scripted UDFs" > If this blog cannot be published by the *February 18, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17394) WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs"
Diogenese Topper created CASSANDRA-17394: Summary: WEBSITE - February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs" Key: CASSANDRA-17394 URL: https://issues.apache.org/jira/browse/CASSANDRA-17394 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with publishing the February 2022 blog "Upgrade Advisory: 3.0, 3.11, 4.0 Possible for Remote Code Execution for Scripted UDFs" If this blog cannot be published by the *February 18, 2022 publish date*, please contact me/suggest changes when possible in the pull request for the appropriate time that the blog will go live (on blog.adoc and in the blog post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494764#comment-17494764 ] Brandon Williams commented on CASSANDRA-17338: -- Nice, +1. > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17338: - Reviewers: Brandon Williams, Brandon Williams Brandon Williams, Brandon Williams (was: Brandon Williams) Status: Review In Progress (was: Patch Available) > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17338: - Status: Ready to Commit (was: Review In Progress) > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[
https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628
]
Brad Schoening edited comment on CASSANDRA-17293 at 2/18/22, 5:22 PM:
--
This would seem to be a different issue unrelated to pytest and maybe should be
a separate Jira to remove futures from requirements.txt.
The Cassandra requirements.txt has a comment which indicates this was inherited
(unnecessarily) from a driver requirement:
{{ requirements.txt:# See python driver docs: futures and six have to be
installed before}}
{{ requirements.txt:futures}}
There appears to be no use of futures in the python code.
The DataStax cassandra-driver has:
{{ futures <=2.2.0}}
{{ # Futures is not required for Python 3, but it works up through 2.2.0
(after which it introduced breaking syntax).}}
{{ # This is left here to make sure install -r works with any runtime. When
installing via setup.py, futures is omitted}}
{{ # for Python 3, in favor of the standard library implementation.}}
{{ # see PYTHON-393}}
[https://github.com/datastax/python-driver/blob/master/requirements.txt]
was (Author: bschoeni):
This would seem to be a different issue unrelated to pytest and maybe should be
a separate Jira to remove futures from requirements.txt.
The Cassandra requirements.txt has a comment which indicates this was inherited
(unnecessarily) from a driver requirement:
{{ requirements.txt:# See python driver docs: futures and six have to be
installed before}}
{{ requirements.txt:futures}}
There appears to be no use of futures in the python code.
The DataStax cassandra-driver has:
{{ futures <=2.2.0}}
{{ # Futures is not required for Python 3, but it works up through 2.2.0
(after which it introduced breaking syntax).}}
{{ # This is left here to make sure install -r works with any runtime. When
installing via setup.py, futures is omitted}}
{{ # for Python 3, in favor of the standard library implementation.}}
{{ # see PYTHON-393}}
[https://github.com/datastax/python-driver/blob/master/requirements.txt]
> Update python test framework from nose to pytest
>
>
> Key: CASSANDRA-17293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17293
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> I had trouble trying to install and run the python nose test from pip
> (nosetest not found).
> According to the homepage of nose at [https://nose.readthedocs.io/en/latest/]
> h1. _Note to Users_
> _Nose has been in maintenance mode for the past several years and will likely
> cease without a new person/team to take over maintainership. New projects
> should consider using [Nose2|https://github.com/nose-devs/nose2],
> [py.test|http://pytest.org/], or just plain unittest/unittest2._
>
> Upgrading to pytest is likely the least effort.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[
https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628
]
Brad Schoening edited comment on CASSANDRA-17293 at 2/18/22, 5:21 PM:
--
This would seem to be a different issue unrelated to pytest and maybe should be
a separate Jira to remove futures from requirements.txt.
The Cassandra requirements.txt has a comment which indicates this was inherited
(unnecessarily) from a driver requirement:
{{ requirements.txt:# See python driver docs: futures and six have to be
installed before}}
{{ requirements.txt:futures}}
There appears to be no use of futures in the python code.
The DataStax cassandra-driver has:
{{ futures <=2.2.0}}
{{ # Futures is not required for Python 3, but it works up through 2.2.0
(after which it introduced breaking syntax).}}
{{ # This is left here to make sure install -r works with any runtime. When
installing via setup.py, futures is omitted}}
{{ # for Python 3, in favor of the standard library implementation.}}
{{ # see PYTHON-393}}
[https://github.com/datastax/python-driver/blob/master/requirements.txt]
was (Author: bschoeni):
This would seem to be a different issue unrelated to pytest and maybe should be
a separate Jira to remove futures from requirements.txt.
The Cassandra requirements.txt has a comment which indicates this was inherited
(unnecessarily) from a driver requirement:
requirements.txt:# See python driver docs: futures and six have to be
installed before
requirements.txt:futures
There appears to be no use of futures in the python code.
The DataStax cassandra-driver states:
futures <=2.2.0
# Futures is not required for Python 3, but it works up through 2.2.0
(after which it introduced breaking syntax).
# This is left here to make sure install -r works with any runtime. When
installing via setup.py, futures is omitted
# for Python 3, in favor of the standard library implementation.
# see PYTHON-393
https://github.com/datastax/python-driver/blob/master/requirements.txt
[https://github.com/datastax/python-driver/blob/master/requirements.txt]
> Update python test framework from nose to pytest
>
>
> Key: CASSANDRA-17293
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17293
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> I had trouble trying to install and run the python nose test from pip
> (nosetest not found).
> According to the homepage of nose at [https://nose.readthedocs.io/en/latest/]
> h1. _Note to Users_
> _Nose has been in maintenance mode for the past several years and will likely
> cease without a new person/team to take over maintainership. New projects
> should consider using [Nose2|https://github.com/nose-devs/nose2],
> [py.test|http://pytest.org/], or just plain unittest/unittest2._
>
> Upgrading to pytest is likely the least effort.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Test and Documentation Plan: The test has been fix and run 10 times locally. No documentation changes are required. Status: Patch Available (was: In Progress) > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494717#comment-17494717 ] Aleksei Zotov commented on CASSANDRA-17338: --- The fix seems to be working locally. Kicked of CI and raised a PR. ||Item||Link|| |PR|[https://github.com/apache/cassandra/pull/1460]| |CI|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1432/]| > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Fix Version/s: 3.0.x > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494711#comment-17494711 ] Aleksei Zotov commented on CASSANDRA-17338: --- I can see failures for 3.0 as well: * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/301/#showFailuresLink] * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/302/#showFailuresLink] * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/306/#showFailuresLink] Similarly to CASSANDRA-17386 the issue is reproducible locally and seems to be fixed in [https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79]. I'll backport necessary changes to 3.0 branch. > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov reassigned CASSANDRA-17338: - Assignee: Aleksei Zotov > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16878) Race in commit log replay can cause rejected mutations
[
https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494674#comment-17494674
]
Aleksey Yeschenko commented on CASSANDRA-16878:
---
bq. What do you think about merging before applying the schema change mutations?
Doesn't that just flip the issue? Now the following scenario is possible:
0. Table table1 does NOT exist
1. {{CREATE TABLE table1}} happens in memory, the schema mutation isn't written
yet
2. Mutation m1 for table table1 validates successfully and is written to the
commit log
3. Schema mutation for {{CREATE TABLE table1}} gets written to the commit log
If you replay these in commit log order, you won't be able to deserialize
mutation m1, as the table will not have been created yet.
> Race in commit log replay can cause rejected mutations
> --
>
> Key: CASSANDRA-16878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16878
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> We don't force order in the execution of replayed mutations and hence a
> mutation can move ahead of or behind a schema change it relies on (e.g.
> added/removed column), which can then cause it to be rejected because of a
> schema mismatch.
> To fix this, we need to identify schema mutations and make sure the log
> enforces their execution after all previous mutations have completed and
> before anything following is started.
> Schema mutations are
> [flushed|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271]
> after being applied, so this only would be a problem if the node abruptly
> stops before flushing the schema mutation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17005:
-
Status: Review In Progress (was: Needs Committer)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exception("Operation
> fa
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17005:
-
Status: Open (was: Patch Available)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exception("Operation
> failed:") """ se
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17005:
-
Status: Patch Available (was: Review In Progress)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exception("Operation
> fa
[jira] [Assigned] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17005:
Assignee: (was: Brandon Williams)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exception("Operation
> failed:"
[jira] [Commented] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494656#comment-17494656
]
Brandon Williams commented on CASSANDRA-17005:
--
I'm not sure why that doesn't show on the main page, but the few occurrences
there are timeouts, and circle passes so I'm not sure there's any surface left
to attack.
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = s
[jira] [Commented] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494654#comment-17494654
]
Ekaterina Dimitrova commented on CASSANDRA-17005:
-
Yes, it seems it is flaky on 4.0
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
[jira] [Comment Edited] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494654#comment-17494654
]
Ekaterina Dimitrova edited comment on CASSANDRA-17005 at 2/18/22, 2:54 PM:
---
Yes, it seems it is flaky on 4.0
https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-4.0/failure/repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair
was (Author: e.dimitrova):
Yes, it seems it is flaky on 4.0
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeo
[jira] [Commented] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494653#comment-17494653
]
Ekaterina Dimitrova commented on CASSANDRA-17005:
-
I think I actually saw it on some branch the other day, let me double check.
Anyway I have to check how is butler doing today :)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * F
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494652#comment-17494652 ] Brandon Williams commented on CASSANDRA-17393: -- No, that's what this is about. > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494647#comment-17494647 ] Ekaterina Dimitrova commented on CASSANDRA-17393: - Do we need it for 4.0 and trunk though? > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494646#comment-17494646 ] Brandon Williams commented on CASSANDRA-17393: -- We still have to support it for branches < 4.0 though. > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494644#comment-17494644 ] Brad Schoening commented on CASSANDRA-17393: This is a driver requirement, so it shouldn't need to be included for Cassandra. Also, Python 2.x is EOL. > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494635#comment-17494635 ] Brandon Williams commented on CASSANDRA-17393: -- I think the proper way to handle this is to explicitly make it only for python2 in setup.py, as the docs state: https://pypi.org/project/futures/ > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494634#comment-17494634 ] Ekaterina Dimitrova commented on CASSANDRA-17393: - Removal of futures is part of my suggestion for 4.0 and trunk as part of the proposed solution in CASSANDRA-17351 > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494631#comment-17494631 ] Brandon Williams commented on CASSANDRA-17293: -- I've opened CASSANDRA-17393 to remove futures. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17393: - Bug Category: Parent values: Correctness(12982) Complexity: Low Hanging Fruit Component/s: CI Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17393) pip tries to install futures in py3
[ https://issues.apache.org/jira/browse/CASSANDRA-17393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17393: Assignee: Brandon Williams > pip tries to install futures in py3 > --- > > Key: CASSANDRA-17393 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > We've seen this problem in CI, and it's also seen (albeit extraneously) on > CASSANDRA-17293. This ticket is to explore removing futures from > requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17393) pip tries to install futures in py3
Brandon Williams created CASSANDRA-17393: Summary: pip tries to install futures in py3 Key: CASSANDRA-17393 URL: https://issues.apache.org/jira/browse/CASSANDRA-17393 Project: Cassandra Issue Type: Bug Reporter: Brandon Williams We've seen this problem in CI, and it's also seen (albeit extraneously) on CASSANDRA-17293. This ticket is to explore removing futures from requirements.txt, and it shouldn't be needed. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/18/22, 2:18 PM: -- This would seem to be a different issue unrelated to pytest and maybe should be a separate Jira to remove futures from requirements.txt. The Cassandra requirements.txt has a comment which indicates this was inherited (unnecessarily) from a driver requirement: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures There appears to be no use of futures in the python code. The DataStax cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 https://github.com/datastax/python-driver/blob/master/requirements.txt [https://github.com/datastax/python-driver/blob/master/requirements.txt] was (Author: bschoeni): This would seem to be a different issue unrelated to pytest and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 [https://github.com/datastax/python-driver/blob/master/requirements.txt] > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/18/22, 2:11 PM: -- This would seem to be a different issue unrelated to pytest and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 [https://github.com/datastax/python-driver/blob/master/requirements.txt] was (Author: bschoeni): This would seem to be a different issue unrelated to pyptest and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 [https://github.com/datastax/python-driver/blob/master/requirements.txt] > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/18/22, 2:11 PM: -- This would seem to be a different issue unrelated to pyptest and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 [https://github.com/datastax/python-driver/blob/master/requirements.txt] was (Author: bschoeni): This would seem to be a different issue and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 https://github.com/datastax/python-driver/blob/master/requirements.txt > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494628#comment-17494628 ] Brad Schoening commented on CASSANDRA-17293: This would seem to be a different issue and maybe should be a Jira to remove futures from requirements.txt. The Cassandra requirements.txt states: requirements.txt:# See python driver docs: futures and six have to be installed before requirements.txt:futures And the cassandra-driver states: futures <=2.2.0 # Futures is not required for Python 3, but it works up through 2.2.0 (after which it introduced breaking syntax). # This is left here to make sure install -r works with any runtime. When installing via setup.py, futures is omitted # for Python 3, in favor of the standard library implementation. # see PYTHON-393 https://github.com/datastax/python-driver/blob/master/requirements.txt > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17368) Investigate OWASP failure report
[ https://issues.apache.org/jira/browse/CASSANDRA-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494603#comment-17494603 ] Brandon Williams edited comment on CASSANDRA-17368 at 2/18/22, 1:26 PM: I've broken out the netty upgrade to CASSANDRA-17392 so we aren't holding back the suppressions for the other branches while that is figured out, so this is ready for review. was (Author: brandon.williams): I've broken out the netty upgrade to CASSANDRA-17392 so we can aren't holding back the suppressions for the other branches while that is figured out, so this is ready for review. > Investigate OWASP failure report > > > Key: CASSANDRA-17368 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17368 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > 4.0: netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.11: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.0: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17384) WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra Release"
[ https://issues.apache.org/jira/browse/CASSANDRA-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17384: --- Fix Version/s: NA (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra-website/commit/e98ea999abd4d2eac1179715509fcb7e30210d02 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed into trunk at e98ea999abd4d2eac1179715509fcb7e30210d02 > WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra > Release" > --- > > Key: CASSANDRA-17384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17384 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Josh McKenzie >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17384-01-blog-index.png, c17384-02-blog-post.png > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Behind the scenes of an Apache Cassandra Release" > If this blog cannot be published by the *February 17, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17368) Investigate OWASP failure report
[ https://issues.apache.org/jira/browse/CASSANDRA-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17368: - Status: Patch Available (was: Open) > Investigate OWASP failure report > > > Key: CASSANDRA-17368 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17368 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > 4.0: netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.11: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.0: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17368) Investigate OWASP failure report
[ https://issues.apache.org/jira/browse/CASSANDRA-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494603#comment-17494603 ] Brandon Williams commented on CASSANDRA-17368: -- I've broken out the netty upgrade to CASSANDRA-17392 so we can aren't holding back the suppressions for the other branches while that is figured out, so this is ready for review. > Investigate OWASP failure report > > > Key: CASSANDRA-17368 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17368 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > 4.0: netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.11: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.0: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17392) Upgrade to netty 4.1.73.Final
[ https://issues.apache.org/jira/browse/CASSANDRA-17392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17392: - Change Category: Operability Complexity: Normal Component/s: Build Fix Version/s: 4.x Status: Open (was: Triage Needed) > Upgrade to netty 4.1.73.Final > - > > Key: CASSANDRA-17392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17392 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.x > > > The current netty version has CVEs as shown in CASSANDRA-17368. There we > suppressed the CVEs for other versions, but for trunk let's investigate > upgrading. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17368) Investigate OWASP failure report
[ https://issues.apache.org/jira/browse/CASSANDRA-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17368: - Fix Version/s: (was: 4.x) > Investigate OWASP failure report > > > Key: CASSANDRA-17368 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17368 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x > > > 4.0: netty-all-4.1.58.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.11: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 > 3.0: netty-all-4.0.44.Final.jar: CVE-2021-43797, CVE-2021-37136, > CVE-2021-37137 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17392) Upgrade to netty 4.1.73.Final
Brandon Williams created CASSANDRA-17392: Summary: Upgrade to netty 4.1.73.Final Key: CASSANDRA-17392 URL: https://issues.apache.org/jira/browse/CASSANDRA-17392 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams The current netty version has CVEs as shown in CASSANDRA-17368. There we suppressed the CVEs for other versions, but for trunk let's investigate upgrading. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494599#comment-17494599 ] Stefan Miklosovic commented on CASSANDRA-17293: --- trunk is same for me, unless i comment futures out, it fails. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494597#comment-17494597
]
Andres de la Peña edited comment on CASSANDRA-17153 at 2/18/22, 1:17 PM:
-
Here is the patch adding the proposed guardrails:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1459]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/20d6dd7f-a453-4a47-84d8-f5fc85d3aa66]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/19736dab-b07f-4fe1-8cac-ab62eec9aa78]|
Unfortunately we cannot know the data size nor the number of items of a
non-frozen collection at write time, because part of the collection could have
already been written, and we don't want to do read before write. Thus, the
suggested approach is:
* At write time the guardrails only check the size of the collection fragment
that is written, without checking for any additional fragments of the
collection that might be already stored. This check is done for both frozen and
not-frozen collections.
* At sstable write time the guardrails are checked again for every non-frozen
collection, so we can detect collections over the thresholds when they are
written to disk or compacted. In this case the action taken by the guardrail is
just emitting a warn/error log message. There isn't a client warning because
this check happens asychronously, and no exception is risen because there isn't
a specific query to abort and we don't want to interrupt the process triggering
the guardrail.
As for testing, the tests for each new guardrail are split between unit tests
and dtests. The unit tests are used for the query-time guardrail check, and the
dtests are used for the flush/compact-time check. Dtests are used because they
have utilities that allow us to easily check the logs and because we wan't to
check that those log messages are printed in replicas, and not only on the
coordinator.
was (Author: adelapena):
Here is the patch adding the proposed guardrails:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1459]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/20d6dd7f-a453-4a47-84d8-f5fc85d3aa66]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/19736dab-b07f-4fe1-8cac-ab62eec9aa78]|
Unfortunately we cannot know the data size nor the number of items of a
non-frozen collection at write time, because part of the collection could have
already been written, and we don't want to do read before write. Thus, the
suggested approach is:
* At write time the guardrails only check the size of the collection fragment
that is written, without checking for any additional fragments of the
collection that might be already stored. This check is done for both frozen and
not-frozen collections.
* At sstable write time the guardrails are checked again for every non-frozen
collection, so we can detect collections over the thresholds when they are
written to disk or compacted. In this case the action taken by the guardrail is
just emitting a warn/error log message. There isn't a warning message because
this happens asychronously, and no exception is risen because there isn't a
specific query to abort and we don't want to interrupt the process triggering
the guardrail.
As for testing, the tests for each new guardrail are split between unit tests
and dtests. The unit tests are used for the query-time guardrail check, and the
dtests are used for the flush/compact-time check. Dtests are used because they
have utilities that allow us to easily check the logs and because we wan't to
check that those log messages are printed in replicas, and not only on the
coordinator.
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
--
[jira] [Updated] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17153:
--
Test and Documentation Plan: New tests are included.
Status: Patch Available (was: In Progress)
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17153:
--
Fix Version/s: 4.x
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494597#comment-17494597
]
Andres de la Peña commented on CASSANDRA-17153:
---
Here is the patch adding the proposed guardrails:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1459]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/20d6dd7f-a453-4a47-84d8-f5fc85d3aa66]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1308/workflows/19736dab-b07f-4fe1-8cac-ab62eec9aa78]|
Unfortunately we cannot know the data size nor the number of items of a
non-frozen collection at write time, because part of the collection could have
already been written, and we don't want to do read before write. Thus, the
suggested approach is:
* At write time the guardrails only check the size of the collection fragment
that is written, without checking for any additional fragments of the
collection that might be already stored. This check is done for both frozen and
not-frozen collections.
* At sstable write time the guardrails are checked again for every non-frozen
collection, so we can detect collections over the thresholds when they are
written to disk or compacted. In this case the action taken by the guardrail is
just emitting a warn/error log message. There isn't a warning message because
this happens asychronously, and no exception is risen because there isn't a
specific query to abort and we don't want to interrupt the process triggering
the guardrail.
As for testing, the tests for each new guardrail are split between unit tests
and dtests. The unit tests are used for the query-time guardrail check, and the
dtests are used for the flush/compact-time check. Dtests are used because they
have utilities that allow us to easily check the logs and because we wan't to
check that those log messages are printed in replicas, and not only on the
coordinator.
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17005:
-
Status: Needs Committer (was: Patch Available)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exceptio
[jira] [Updated] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17005:
-
Test and Documentation Plan: none
Status: Patch Available (was: In Progress)
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in
[jira] [Updated] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Potepalov updated CASSANDRA-17367:
-
Status: Patch Available (was: Open)
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494588#comment-17494588
]
Brandon Williams commented on CASSANDRA-17005:
--
I think this must have been fixed somewhere along the way. I can't get it to
fail after many runs, I don't see it [in
butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-4.0/cassandra-4.0],
and it passes repeated runs [in
circle|https://app.circleci.com/pipelines/github/driftx/cassandra/371/workflows/d462e8b9-1fe7-4159-ac41-404246eb47ea/jobs/4219].
I suggest we close.
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is
[jira] [Commented] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494587#comment-17494587
]
Dmitry Potepalov commented on CASSANDRA-17367:
--
Attached updated patches with the test for trunk and 4.0. Seems that there was
no test for sstableloader that actually did any streaming with encryption
enabled, so I modified the "bulkLoaderSuccessfullyConnectsOverSsl" to do some
streaming and verify that data is accessible on the cluster afterwards.
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17005) Fix test dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
[
https://issues.apache.org/jira/browse/CASSANDRA-17005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17005:
Assignee: Brandon Williams
> Fix test
> dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair
> --
>
> Key: CASSANDRA-17005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17005
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
>
> [dtest.repair_tests.incremental_repair_test.TestIncRepair.test_multiple_repair|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/dtest.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/]
> is flaky:
> h3.
> {code:java}
> Error Message
> cassandra.OperationTimedOut: errors={'127.0.0.2:9042': 'Client request
> timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> Stacktrace
> self = 0x7ff52f4f4fd0> def test_multiple_repair(self): """ * Launch a three node
> cluster * Create a keyspace with RF 3 and a table * Insert 49 rows * Stop
> node3 * Insert 50 more rows * Restart node3 * Issue an incremental repair on
> node3 * Stop node2 * Insert a final50 rows * Restart node2 * Issue an
> incremental repair on node2 * Replace node3 with a new node * Verify data
> integrity # TODO: Several more verifications of data need to be interspersed
> throughout the test. The final assertion is insufficient. @jira_ticket
> CASSANDRA-10644 """ cluster = self.cluster cluster.populate(3).start() node1,
> node2, node3 = cluster.nodelist() session =
> self.patient_cql_connection(node1) create_ks(session, 'ks', 3) if
> cluster.version() < '4.0': create_cf(session, 'cf', read_repair=0.0,
> columns={'c1': 'text', 'c2': 'text'}) else: create_cf(session, 'cf',
> columns={'c1': 'text', 'c2': 'text'}) logger.debug("insert data")
> insert_c1c2(session, keys=list(range(1, 50)),
> consistency=ConsistencyLevel.ALL) node1.flush() logger.debug("bringing down
> node 3") node3.flush() node3.stop(gently=False) logger.debug("inserting
> additional data into node 1 and 2") insert_c1c2(session, keys=list(range(50,
> 100)), consistency=ConsistencyLevel.TWO) node1.flush() node2.flush()
> logger.debug("restarting and repairing node 3")
> node3.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node3.repair() else: node3.nodetool("repair -par -inc") # wait stream
> handlers to be closed on windows # after session is finished (See
> CASSANDRA-10644) if is_win: time.sleep(2) logger.debug("stopping node 2")
> node2.stop(gently=False) logger.debug("inserting data in nodes 1 and 3")
> insert_c1c2(session, keys=list(range(100, 150)),
> consistency=ConsistencyLevel.TWO) node1.flush() node3.flush()
> logger.debug("start and repair node 2")
> node2.start(wait_for_binary_proto=True) if cluster.version() >= "2.2":
> node2.repair() else: node2.nodetool("repair -par -inc") logger.debug("replace
> node and check data integrity") node3.stop(gently=False) node5 =
> Node('node5', cluster, True, ('127.0.0.5', 9160), ('127.0.0.5', 7000),
> '7500', '0', None, ('127.0.0.5', 9042)) cluster.add(node5, False,
> data_center="dc1") node5.start(replace_address='127.0.0.3') >
> assert_one(session, "SELECT COUNT(*) FROM ks.cf LIMIT 200", [149])
> repair_tests/incremental_repair_test.py:300: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ tools/assertions.py:130: in
> assert_one res = session.execute(simple_query)
> ../venv/src/cassandra-driver/cassandra/cluster.py:2618: in execute return
> self.execute_async(query, parameters, trace, custom_payload, timeout,
> execution_profile, paging_state, host, execute_as).result() _ _ _ _ _ _ _ _ _
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self =
> See Session.execute[_async](timeout)'}, last_host=127.0.0.2:9042
> coordinator_host=None> def result(self): """ Return the final result or raise
> an Exception if errors were encountered. If the final result or error has not
> been set yet, this method will block until it is set, or the timeout set for
> the request expires. Timeout is specified in the Session request execution
> functions. If the timeout is exceeded, an :exc:`cassandra.OperationTimedOut`
> will be raised. This is a client-side timeout. For more information about
> server-side coordinator timeouts, see :class:`.policies.RetryPolicy`. Example
> usage:: >>> future = session.execute_async("SELECT * FROM mycf") >>> # do
> other stuff... >>> try: ... rows = future.result() ... for row in rows: ...
> ... # process results ... except Exception: ... log.exc
[jira] [Updated] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Potepalov updated CASSANDRA-17367:
-
Attachment: 17367-4.0.txt
17367-trunk.txt
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17367-4.0.txt, 17367-trunk.txt
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Potepalov updated CASSANDRA-17367:
-
Attachment: (was: 17367-4.0.txt)
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17367) sstableloader ignores streaming encryption settings
[
https://issues.apache.org/jira/browse/CASSANDRA-17367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Potepalov updated CASSANDRA-17367:
-
Attachment: (was: 17367-trunk.txt)
> sstableloader ignores streaming encryption settings
> ---
>
> Key: CASSANDRA-17367
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17367
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/bulk load
>Reporter: Dmitry Potepalov
>Assignee: Dmitry Potepalov
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Reproducible in Cassandra 4.x. If one configures encryption for streaming in
> config yaml fed to sstableloader like this
> {{server_encryption_options:}}
> {{ internode_encryption: all}}
> {{ keystore: sstableloader.keystore.p12}}
> {{ keystore_password: changeit}}
> {{ truststore: sstableloader.truststore.jks}}
> {{ truststore_password: changeit}}
> then sstableloader should perform an SSL handshake on the streaming
> connections and encrypt the payload. But this does not happen. Judging by the
> TCPdump of the outgoing traffic on the internode port, sstableloader sends
> plaintext traffic. This is the TCP payload of the first packet that
> sstableloader sends after establishing TCP connection:
> {{ca 55 2d fa 0c 0c 0c 08 06 0a f0 01 f9 1b 58 a8 32 f2 d0}}
> The first 4 bytes look like Cassandra protocol magic, not like a client hello.
> I've discovered the issue while trying to migrate some data to a Cassandra 4
> listening on the legacy ssl storage port (therefore, accepting only encrypted
> connections on that port). Streaming phase of the migration failed with a
> "connection closed" error, which hints that the connection was closed
> server-side.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (f2b1412 -> ccac41f)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard f2b1412 generate docs for 03bdf7ac
add e98ea99 February 2022 blog "Behind the scenes of an Apache Cassandra
Release"
add ccac41f generate docs for e98ea999
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (f2b1412)
\
N -- N -- N refs/heads/asf-site (ccac41f)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
...ache-cassandra-release-unsplash-lajos-szabo.jpg | Bin 0 -> 1756830 bytes
content/_/blog.html| 24 +++
...the-scenes-of-an-Apache-Cassandra-Release.html} | 73 +++--
content/search-index.js| 2 +-
...ache-cassandra-release-unsplash-lajos-szabo.jpg | Bin 0 -> 1756830 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++
...-the-scenes-of-an-Apache-Cassandra-Release.adoc | 45 +
site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084
bytes
8 files changed, 131 insertions(+), 37 deletions(-)
create mode 100644
content/_/_images/blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg
copy content/_/blog/{World-Party.html =>
Behind-the-scenes-of-an-Apache-Cassandra-Release.html} (65%)
create mode 100644
site-content/source/modules/ROOT/images/blog/behind-the-scenes-of-an-apache-cassandra-release-unsplash-lajos-szabo.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Behind-the-scenes-of-an-Apache-Cassandra-Release.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16962) Fix dtest-novnode.materialized_views_test.TestMaterializedViews.test_drop_with_stopped_build
[
https://issues.apache.org/jira/browse/CASSANDRA-16962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494580#comment-17494580
]
Brandon Williams commented on CASSANDRA-16962:
--
+1
> Fix
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_drop_with_stopped_build
>
>
> Key: CASSANDRA-16962
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16962
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Failed in Jenkins 4.0:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/213/testReport/junit/dtest-novnode.materialized_views_test/TestMaterializedViews/test_drop_with_stopped_build/]
>
>
> {code:java}
> dtest-novnode.materialized_views_test.TestMaterializedViews.test_drop_with_stopped_build
> (from Cassandra dtests)
> Failing for the past 1 build (Since #213 ) Took 1 min 33 sec. Failed 1
> times in the last 30 runs. Flakiness: 3%, Stability: 96% Error Message
> AssertionError: Expected [[5000]] from SELECT COUNT(*) FROM t_by_v, but got
> [[4991]]
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12783) Break up large MV mutations to prevent OOMs
[ https://issues.apache.org/jira/browse/CASSANDRA-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12783: - Test and Documentation Plan: run CI Status: Patch Available (was: In Progress) > Break up large MV mutations to prevent OOMs > --- > > Key: CASSANDRA-12783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12783 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Local Write-Read Paths >Reporter: Carl Yeksigian >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > We only use the code path added in CASSANDRA-12268 for the view builder > because otherwise we would break the contract of the batchlog, where some > mutations may be written and pushed out before the whole batch log has been > saved. > We would need to ensure that all of the updates make it to the batchlog > before allowing the batchlog manager to try to replay them, but also before > we start pushing out updates to the paired replicas. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12783) Break up large MV mutations to prevent OOMs
[ https://issues.apache.org/jira/browse/CASSANDRA-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-12783: - Status: Open (was: Patch Available) > Break up large MV mutations to prevent OOMs > --- > > Key: CASSANDRA-12783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12783 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Local Write-Read Paths >Reporter: Carl Yeksigian >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > We only use the code path added in CASSANDRA-12268 for the view builder > because otherwise we would break the contract of the batchlog, where some > mutations may be written and pushed out before the whole batch log has been > saved. > We would need to ensure that all of the updates make it to the batchlog > before allowing the batchlog manager to try to replay them, but also before > we start pushing out updates to the paired replicas. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12783) Break up large MV mutations to prevent OOMs
[ https://issues.apache.org/jira/browse/CASSANDRA-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-12783: Assignee: (was: Kurt Greaves) > Break up large MV mutations to prevent OOMs > --- > > Key: CASSANDRA-12783 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12783 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views, Legacy/Local Write-Read Paths >Reporter: Carl Yeksigian >Priority: Normal > Labels: 4.0-feature-freeze-review-requested > Fix For: 4.x > > > We only use the code path added in CASSANDRA-12268 for the view builder > because otherwise we would break the contract of the batchlog, where some > mutations may be written and pushed out before the whole batch log has been > saved. > We would need to ensure that all of the updates make it to the batchlog > before allowing the batchlog manager to try to replay them, but also before > we start pushing out updates to the paired replicas. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494579#comment-17494579
]
Erick Ramirez commented on CASSANDRA-17388:
---
[~mck] you're absolutely right. I was going to bring it up separately. There's
a bit of cleanup involved mostly for {{CHANGES.txt}} but I'm pretty sure I've
seen oddities in {{NEWS.txt}} over the last few months. I'll add it to my to-do
list. 👍
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494560#comment-17494560
]
Berenguer Blasi commented on CASSANDRA-17186:
-
Ok thx [~adelapena] that makes sense. It looks mostly good to me. I just want
to look a bit more how you filter query types based on state which is an area I
am not proficient in. I think next week we'll be merging :-)
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17334) Pre hashed passwords in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494542#comment-17494542
]
Bowen Song commented on CASSANDRA-17334:
Thank you [~bereng] . It all sounds good to me.
> Pre hashed passwords in CQL
> ---
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
> Based on original works from [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17388:
---
Reviewers: Marcus Eriksson, Michael Semb Wever (was: Marcus Eriksson)
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-17388:
---
Source Control Link:
https://github.com/apache/cassandra/commit/679740ff487490d7d2fb0bf0d090e955a8092404
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[679740ff487490d7d2fb0bf0d090e955a8092404|https://github.com/apache/cassandra/commit/679740ff487490d7d2fb0bf0d090e955a8092404].
Note, despite the `fix versions`, these changes are not included inside those
releases.
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0.2, 3.11.12, 3.0.26
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17388) DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
[
https://issues.apache.org/jira/browse/CASSANDRA-17388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494512#comment-17494512
]
Michael Semb Wever commented on CASSANDRA-17388:
+1
(through trunk patch was for 4.0, and trunk CHANGES.txt looks wrong including
4.0.x patch versions (but nothing to do with this ticket))
> DOC - Add entries to CHANGES.txt, NEWS.txt about CVE-2021-44521
> ---
>
> Key: CASSANDRA-17388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17388
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/NEWS.txt
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Document changes made by CASSANDRA-17352 in {{NEWS.txt}} and {{CHANGES.txt}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
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-3.11' into cassandra-4.0
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 commit 85fd49f2cf11ba6587f87c552e9081f856c74f6f Merge: f8b3f60 593872c Author: Mick Semb Wever AuthorDate: Fri Feb 18 11:14:50 2022 +0100 Merge branch 'cassandra-3.11' into cassandra-4.0 CHANGES.txt | 1 + NEWS.txt| 18 ++ 2 files changed, 19 insertions(+) diff --cc CHANGES.txt index 92efa8d,a7a7eed..bc76062 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -4,46 -4,20 +4,47 @@@ Merged from 3.0 * Lazy transaction log replica creation allows incorrect replica content divergence during anticompaction (CASSANDRA-17273) * LeveledCompactionStrategy disk space check improvements (CASSANDRA-17272) +4.0.3 + * Deprecate otc_coalescing_strategy, otc_coalescing_window_us, otc_coalescing_enough_coalesced_messages, + otc_backlog_expiration_interval_ms (CASSANDRA-17377) + * Improve start up processing of Incremental Repair information read from system.repairs (CASSANDRA-17342) -3.11.12 +4.0.2 + * Extend operator control over the UDF threading model for CVE-2021-44521 (CASSANDRA-17352) - * Upgrade snakeyaml to 1.26 in 3.11 (CASSANDRA=17028) + * Full Java 11 support (CASSANDRA-16894) + * Remove unused 'geomet' package from cqlsh path (CASSANDRA-17271) + * Removed unused 'cql' dependency (CASSANDRA-17247) + * Don't block gossip when clearing repair snapshots (CASSANDRA-17168) + * Deduplicate warnings for deprecated parameters (changed names) (CASSANDRA-17160) + * Update ant-junit to version 1.10.12 (CASSANDRA-17218) + * Add droppable tombstone metrics to nodetool tablestats (CASSANDRA-16308) + * Fix disk failure triggered when enabling FQL on an unclean directory (CASSANDRA-17136) + * Fixed broken classpath when multiple jars in build directory (CASSANDRA-17129) + * DebuggableThreadPoolExecutor does not propagate client warnings (CASSANDRA-17072) + * internode_send_buff_size_in_bytes and internode_recv_buff_size_in_bytes have new names. Backward compatibility with the old names added (CASSANDRA-17141) + * Remove unused configuration parameters from cassandra.yaml (CASSANDRA-17132) + * Queries performed with NODE_LOCAL consistency level do not update request metrics (CASSANDRA-17052) + * Fix multiple full sources can be select unexpectedly for bootstrap streaming (CASSANDRA-16945) + * Fix cassandra.yaml formatting of parameters (CASSANDRA-17131) + * Add backward compatibility for CQLSSTableWriter Date fields (CASSANDRA-17117) + * Push initial client connection messages to trace (CASSANDRA-17038) + * Correct the internode message timestamp if sending node has wrapped (CASSANDRA-16997) + * Avoid race causing us to return null in RangesAtEndpoint (CASSANDRA-16965) + * Avoid rewriting all sstables during cleanup when transient replication is enabled (CASSANDRA-16966) + * Prevent CQLSH from failure on Python 3.10 (CASSANDRA-16987) + * Avoid trying to acquire 0 permits from the rate limiter when taking snapshot (CASSANDRA-16872) + * Upgrade Caffeine to 2.5.6 (CASSANDRA-15153) + * Include SASI components to snapshots (CASSANDRA-15134) + * Fix missed wait latencies in the output of `nodetool tpstats -F` (CASSANDRA-16938) + * Remove all the state pollution between tests in SSTableReaderTest (CASSANDRA-16888) + * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) + * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) + * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) +Merged from 3.11: * Add key validation to ssstablescrub (CASSANDRA-16969) * Update Jackson from 2.9.10 to 2.12.5 (CASSANDRA-16851) - * Include SASI components to snapshots (CASSANDRA-15134) * Make assassinate more resilient to missing tokens (CASSANDRA-16847) - * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) - * Validate SASI tokenizer options before adding index to schema (CASSANDRA-15135) - * Fixup scrub output when no data post-scrub and clear up old use of row, which really means partition (CASSANDRA-16835) - * Fix ant-junit dependency issue (CASSANDRA-16827) - * Reduce thread contention in CommitLogSegment and HintsBuffer (CASSANDRA-16072) - * Avoid sending CDC column if not enabled (CASSANDRA-16770) Merged from 3.0: * Fix conversion from megabits to bytes in streaming rate limiter (CASSANDRA-17243) * Upgrade logback to 1.2.9 (CASSANDRA-17204) diff --cc NEWS.txt index 8599c36,1559aa8..eac73f5 --- a/NEWS.txt +++ b/NEWS.txt @@@ -18,6 -18,33 +18,24 @@@ CASSANDRA-14092.txt file If you use or plan to use very large TTLS (10 to 20 years), read CASSANDRA-14092.txt for more information. -PLEASE READ
