[jira] [Updated] (CASSANDRA-15905) cqlsh not able to fetch all rows when in batch mode
[
https://issues.apache.org/jira/browse/CASSANDRA-15905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-15905:
--
Description:
The cqlsh in trunk only display the first page when running in the batch mode,
i.e. using {{--execute}} or {{--file}} option.
It is a change of behavior. In 3.x branches, the cqlsh returns all rows.
It can be reproduced in 3 steps.
{code:java}
1. ccm create trunk -v git:trunk -n1 && ccm start
2. tools/bin/cassandra-stress write n=1k -schema keyspace="keyspace1" //
write 1000 rows
3. bin/cqlsh -e "SELECT * FROM keyspace1.standard1;"//
fetch all rows
{code}
There are 1000 rows written. But the output in step 3 will only list 100 rows,
which is the first page.
{code:java}
➜ bin/cqlsh -e "SELECT * FROM keyspace1.standard1" | wc -l
105{code}
The related change was introduced in
https://issues.apache.org/jira/browse/CASSANDRA-11534, where the cqlsh.py
script no longer fetch all rows when not using tty in the print_result method.
was:
The cqlsh in trunk only display the first page when running in the batch mode,
i.e. using {{\-\-execute}} or {{\-\-file}} option.
It is a change of behavior. In 3.x branches, the cqlsh returns all rows.
It can be reproduced in 3 steps.
{code:java}
1. ccm create trunk -v git:trunk -n1 && ccm start
2. tools/bin/cassandra-stress write n=1k -schema keyspace="keyspace1"
3. bin/cqlsh -e "SELECT * FROM keyspace1.standard1;"
{code}
There are 1000 rows written. But the output in step 3 will only list 100 rows,
which is the first page.
The related change was introduced in
https://issues.apache.org/jira/browse/CASSANDRA-11534, where the cqlsh.py
script no longer fetch all rows when not using tty in the print_result method.
> cqlsh not able to fetch all rows when in batch mode
> ---
>
> Key: CASSANDRA-15905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15905
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Priority: Normal
>
> The cqlsh in trunk only display the first page when running in the batch
> mode, i.e. using {{--execute}} or {{--file}} option.
>
> It is a change of behavior. In 3.x branches, the cqlsh returns all rows.
>
> It can be reproduced in 3 steps.
> {code:java}
> 1. ccm create trunk -v git:trunk -n1 && ccm start
> 2. tools/bin/cassandra-stress write n=1k -schema keyspace="keyspace1" //
> write 1000 rows
> 3. bin/cqlsh -e "SELECT * FROM keyspace1.standard1;"//
> fetch all rows
> {code}
>
> There are 1000 rows written. But the output in step 3 will only list 100
> rows, which is the first page.
> {code:java}
> ➜ bin/cqlsh -e "SELECT * FROM keyspace1.standard1" | wc -l
> 105{code}
>
> The related change was introduced in
> https://issues.apache.org/jira/browse/CASSANDRA-11534, where the cqlsh.py
> script no longer fetch all rows when not using tty in the print_result
> method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14825) Expose table schema for drivers
[ https://issues.apache.org/jira/browse/CASSANDRA-14825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146709#comment-17146709 ] Dinesh Joshi commented on CASSANDRA-14825: -- Hi [~blerer], the changes look ok but there are some failures that I think we should investigate. I have kicked off a circleci jobs ([j11|https://circleci.com/workflow-run/7eb01c14-efa7-4f67-9172-c7e31bc42e33] and [j8|https://circleci.com/workflow-run/a2780b93-14f5-4e8e-8eae-2841ac412c07]) on trunk to see if those failures are also on trunk. If they are then we're not introducing a new regression so we can go ahead and merge. > Expose table schema for drivers > --- > > Key: CASSANDRA-14825 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14825 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Chris Lohfink >Assignee: Robert Stupp >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the drivers recreate the CQL for the tables by putting together the > system table values. This is very difficult to keep up to date and buggy > enough that its only even supported in Java and Python drivers. Cassandra > already has some limited output available for snapshots that we could provide > in a virtual table or new query that the drivers can fetch. This can greatly > reduce the complexity of drivers while also reducing bugs like > CASSANDRA-14822 as the underlying schema and properties change. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14816) Add Operating System Specific Setup Documentation for Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-14816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland reassigned CASSANDRA-14816:
-
Assignee: Lorina Poland
> Add Operating System Specific Setup Documentation for Cassandra
> ---
>
> Key: CASSANDRA-14816
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14816
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Joey Lynch
>Assignee: Lorina Poland
>Priority: Low
>
> There are a number of operating system tunings that can vastly improve
> Cassandra's performance on Linux in particular things like:
> # Setting {{/sys/block/${DEVICE}/queue/read_ahead_kb}} to something more
> reasonable like 32
> # Setting the qdisc on modern linux to something better like {{tc-fq}} with
> {{bbr}}
> # Setting {{nofile}} ulimits properly and {{fs.file-max}}
> # Potentially raising {{vm.max_map_count}} even higher than the default
> debian package does
> # Using raid instead of jbod
> # Mounting /tmp on a tmpfs and turning back on {{PerfDisableSharedMem}}
> And many more ... I think many of the recommendations from [Amy
> Tobey's|https://tobert.github.io/pages/als-cassandra-21-tuning-guide.html]
> 2.1 guide may still be pretty relevant.
> Perhaps we can document some of these in the website's Operations section?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15831) Please update Apache Cassandra Repo link in install docs
[ https://issues.apache.org/jira/browse/CASSANDRA-15831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorina Poland reassigned CASSANDRA-15831: - Assignee: Lorina Poland > Please update Apache Cassandra Repo link in install docs > > > Key: CASSANDRA-15831 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15831 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: I N V A L I D >Assignee: Lorina Poland >Priority: Normal > > In the very first section of Install Docs > Add the Apache Cassandra repository keys to the list of trusted keys on the > server: > > $ curl https://www.apache.org/dist/cassandra/KEYS | sudo apt-key - [Not > working] > > Please change the address. I found this working: > > curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15832) Typo in website documentation for file "mvs.rst"
[
https://issues.apache.org/jira/browse/CASSANDRA-15832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146550#comment-17146550
]
Lorina Poland commented on CASSANDRA-15832:
---
I am fixing this typo as part of the doc website redo to Asciidoc.
> Typo in website documentation for file "mvs.rst"
> -
>
> Key: CASSANDRA-15832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15832
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Tajinder Singh
>Assignee: Lorina Poland
>Priority: Normal
>
> It appears that there is a typo in the doc for mvs.rst file. Please refer
> this link -
> [https://cassandra.apache.org/doc/latest/cql/mvs.html#drop-materialized-view]
> _Current sentence in doc:_
> "Dropping a materialized view {color:#de350b}*users* {color}the DROP
> MATERIALIZED VIEW statement:"
> _Expected sentence in doc:_
> "Dropping a materialized view {color:#00875a}*using* {color}the DROP
> MATERIALIZED VIEW statement:"
> _Patch for proposed fix:_
> [https://github.com/tsingh2k15/cassandra/commit/1a56c295843bd74f2e856c01fa76a4676875dc7c]
>
> Please review and let me know if this patch can be accepted as a fix?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15832) Typo in website documentation for file "mvs.rst"
[
https://issues.apache.org/jira/browse/CASSANDRA-15832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lorina Poland reassigned CASSANDRA-15832:
-
Assignee: Lorina Poland
> Typo in website documentation for file "mvs.rst"
> -
>
> Key: CASSANDRA-15832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15832
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation/Website
>Reporter: Tajinder Singh
>Assignee: Lorina Poland
>Priority: Normal
>
> It appears that there is a typo in the doc for mvs.rst file. Please refer
> this link -
> [https://cassandra.apache.org/doc/latest/cql/mvs.html#drop-materialized-view]
> _Current sentence in doc:_
> "Dropping a materialized view {color:#de350b}*users* {color}the DROP
> MATERIALIZED VIEW statement:"
> _Expected sentence in doc:_
> "Dropping a materialized view {color:#00875a}*using* {color}the DROP
> MATERIALIZED VIEW statement:"
> _Patch for proposed fix:_
> [https://github.com/tsingh2k15/cassandra/commit/1a56c295843bd74f2e856c01fa76a4676875dc7c]
>
> Please review and let me know if this patch can be accepted as a fix?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15814) order by descending on frozen list not working
[
https://issues.apache.org/jira/browse/CASSANDRA-15814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-15814:
--
Bug Category: Parent values: Correctness(12982)Level 1 values: API /
Semantic Implementation(12988)
Complexity: Normal
Component/s: CQL/Interpreter
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> order by descending on frozen list not working
> --
>
> Key: CASSANDRA-15814
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15814
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Felipe Perez
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 40m
> Remaining Estimate: 0h
>
> By creating a table like the following:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> )
> {code}
> It works and version is ordered in an ascending order. But when trying to
> order in descending order:
> {code:java}
> CREATE TABLE IF NOT EXISTS software (
> name ascii,
> version frozen>,
> data ascii,
> PRIMARY KEY(name,version)
> ) WITH CLUSTERING ORDER BY (version DESC);
> {code}
> The table is created normally, but when trying to insert a row:
> {code:java}
> insert into software(name, version) values ('t1', [2,10,30,40,50]);
> {code}
> Cassandra throws an error:
> {code:java}
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Invalid
> list literal for version of type frozen>"
> {code}
> The goal here is that I would like to get the last version of a software.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15878) Ec2Snitch fails on upgrade in legacy mode
[
https://issues.apache.org/jira/browse/CASSANDRA-15878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146442#comment-17146442
]
Alexander Dejanovski commented on CASSANDRA-15878:
--
I've pushed a commit with a potential fix and updated unit tests:
[https://github.com/apache/cassandra/pull/653/commits/7a53846a217102143ae56416ebcf534c59de93e6]
[~jolynch], I'd love to have your input on this since you reviewed the original
ticket that brought this change.
Are there cases I'm not seeing where the dc name would be useful to check?
> Ec2Snitch fails on upgrade in legacy mode
> -
>
> Key: CASSANDRA-15878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15878
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
>Reporter: Alexander Dejanovski
>Assignee: Alexander Dejanovski
>Priority: Normal
> Fix For: 4.0-beta
>
>
> CASSANDRA-7839 changed the way the EC2 DC/Rack naming was handled in the
> Ec2Snitch to match AWS conventions.
> The "legacy" mode was introduced to allow upgrades from Cassandra 3.0/3.x and
> keep the same naming as before (while the "standard" mode uses the new naming
> convention).
> When performing an upgrade in the us-west-2 region, the second node failed to
> start with the following exception:
>
> {code:java}
> ERROR [main] 2020-06-16 09:14:42,218 Ec2Snitch.java:210 - This ec2-enabled
> snitch appears to be using the legacy naming scheme for regions, but existing
> nodes in cluster are using the opposite: region(s) = [us-west-2],
> availability zone(s) = [2a]. Please check the ec2_naming_scheme property in
> the cassandra-rackdc.properties configuration file for more details.
> ERROR [main] 2020-06-16 09:14:42,219 CassandraDaemon.java:789 - Exception
> encountered during startup
> java.lang.IllegalStateException: null
> at
> org.apache.cassandra.service.StorageService.validateEndpointSnitch(StorageService.java:573)
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:530)
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:800)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:610)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:373)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:650)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:767)
> {code}
>
> The exception leads back to [this piece of
> code|https://github.com/apache/cassandra/blob/cassandra-4.0-alpha4/src/java/org/apache/cassandra/locator/Ec2Snitch.java#L183-L185].
> After adding some logging, it turned out the DC name of the first upgraded
> node was considered invalid as a legacy one:
> {code:java}
> INFO [main] 2020-06-16 09:14:42,216 Ec2Snitch.java:183 - Detected DC
> us-west-2
> INFO [main] 2020-06-16 09:14:42,217 Ec2Snitch.java:185 -
> dcUsesLegacyFormat=false / usingLegacyNaming=true
> ERROR [main] 2020-06-16 09:14:42,217 Ec2Snitch.java:188 - Invalid DC name
> us-west-2
> {code}
>
> The problem is that the regex that's used to identify legacy dc names will
> match both old and new names :
> {code:java}
> boolean dcUsesLegacyFormat = !dc.matches("[a-z]+-[a-z].+-[\\d].*");
> {code}
> Knowing that some dc names didn't change between the two modes (us-west-2 for
> example), I don't see how we can use the dc names to detect if the legacy
> mode is being used by other nodes in the cluster.
>
> The rack names on the other hand are totally different in the legacy and
> standard modes and can be used to detect mismatching settings.
>
> My go to fix would be to drop the check on datacenters by removing the
> following lines:
> [https://github.com/apache/cassandra/blob/cassandra-4.0-alpha4/src/java/org/apache/cassandra/locator/Ec2Snitch.java#L172-L186]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-15663:
-
Test and Documentation Plan:
Thanks Alan!
Here are the patches:
* PR to update python driver in Cassandra 3.11 -
[https://github.com/apache/cassandra/pull/654]
* PR to fix {{test_describe_functions}} broken by driver upgrade -
[https://github.com/apache/cassandra-dtest/pull/81]
CI run -
[https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/154/tests/]
I checked the rest of the failing tests manually. Test failures either do not
reproduce locally or fail as well on the base branch.
Status: Patch Available (was: In Progress)
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15663) DESCRIBE KEYSPACE does not properly quote table names
[
https://issues.apache.org/jira/browse/CASSANDRA-15663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146374#comment-17146374
]
Aleksandr Sorokoumov commented on CASSANDRA-15663:
--
Thanks Alan!
Here are the patches:
* PR to update python driver in Cassandra 3.11 -
[https://github.com/apache/cassandra/pull/654]
* PR to fix {{test_describe_functions}} broken by driver upgrade -
[https://github.com/apache/cassandra-dtest/pull/81]
CI run -
[https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/154/tests/]
I checked the rest of the failing tests manually. Test failures either do not
reproduce locally or fail as well on the base branch.
> DESCRIBE KEYSPACE does not properly quote table names
> -
>
> Key: CASSANDRA-15663
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15663
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Syntax
>Reporter: Oskar Liljeblad
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.11.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> How to reproduce (3.11.6) - cqlsh:
> {code}
> CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
> DESCRIBE KEYSPACE test1;
> {code}
> Output will be:
> {code}
> CREATE TABLE test1.default (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> Output should be:
> {code}
> CREATE TABLE test1."default" (
> id text PRIMARY KEY,
> data text,
> etag text
> ) WITH [..]
> {code}
> If you try to run {{CREATE TABLE test1.default [..]}} you will get an error
> SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE
> TABLE test1.[default]...)
> Oskar Liljeblad
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146360#comment-17146360
]
Ekaterina Dimitrova commented on CASSANDRA-13994:
-
[~jmckenzie] Personally, I don't see a reason not to move it to beta if we cut
index removal from its scope and only remove the already not used dead code.
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-alpha
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-15146:
Resolution: Fixed
Status: Resolved (was: Open)
All the renaming happens at once in CASSANDRA-15234. This one is considered
too.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {noformat}
> server_encryption_options:
>
> # set to true for allowing secure incoming connections
>
> enabled: false
>
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
>
>
>
>
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
>
> enable_legacy_ssl_storage_port: false
>
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
>
> keystore: conf/.keystore
>
> keystore_password: cassandra
>
> truststore: conf/.truststore
>
> truststore_password: cassandra
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
> desired level of encryption (recommended {{all}}) and restart Cassandra
> 2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third
> restart to first change {{optional}} to {{true}}, which given my
> understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146355#comment-17146355
]
Ekaterina Dimitrova commented on CASSANDRA-15146:
-
Closing this one as duplicate, the annotation for the name change of
server_encryption_options to internode_encryption will be added as part of
CASSANDRA-15234.
I take the responsibility to add the commit here later for the record.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {noformat}
> server_encryption_options:
>
> # set to true for allowing secure incoming connections
>
> enabled: false
>
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
>
>
>
>
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
>
> enable_legacy_ssl_storage_port: false
>
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
>
> keystore: conf/.keystore
>
> keystore_password: cassandra
>
> truststore: conf/.truststore
>
> truststore_password: cassandra
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
> desired level of encryption (recommended {{all}}) and restart Cassandra
> 2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third
> restart to first change {{optional}} to {{true}}, which given my
> understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13994) Remove COMPACT STORAGE internals before 4.0 release
[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146343#comment-17146343
]
Josh McKenzie commented on CASSANDRA-13994:
---
{quote}This ticket just removes dead code, not _that_ much of it, and it's
hardly a chirurgical removal.
{quote}
Am I too optimistic in reading this as "this ticket could be appropriate for
the beta phase"?
> Remove COMPACT STORAGE internals before 4.0 release
> ---
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
>Reporter: Alex Petrov
>Assignee: Ekaterina Dimitrova
>Priority: Low
> Fix For: 4.0, 4.0-alpha
>
>
> 4.0 comes without thrift (after [CASSANDRA-5]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15901) Force jenkins tests to run on the private VPC IP
[
https://issues.apache.org/jira/browse/CASSANDRA-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146160#comment-17146160
]
Berenguer Blasi commented on CASSANDRA-15901:
-
After discussion with [~mck] it seems the underlying root cause is that some
tests don't init the daemon. Hence the config/listen_address are never loaded
and effective. We came up with the following course of action:
* Make all ci-cass agents fail consistently, so any new tests will get
reported.
* Fix all current tests to init the daemon correctly
* Once ci-cass is in good shape we can link the report for the commit into the
Jira ticket
* Explore ways to make that fail locally so you get the failure pre-push
rather than post-commit/ci-cass run
> Force jenkins tests to run on the private VPC IP
>
>
> Key: CASSANDRA-15901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15901
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Many of the ci-cassandra jenkins runs fail on {{ip-10-0-5-5: Name or service
> not known}}. CASSANDRA-15622 addressed some of these but many still remain.
> Currently test C* nodes are either failing or listening on a public ip
> depending on which agent they end up.
> The idea behind this ticket is to make ant force the private VPC ip in the
> cassandra yaml when building, this will force the nodes to listen on the
> correct ip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13148) Systemd support for RPM
[ https://issues.apache.org/jira/browse/CASSANDRA-13148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146153#comment-17146153 ] Nicolas Chauvet commented on CASSANDRA-13148: - It would be fine to have someone assignee for the task. If anyone know how this issue can be escalated ? Please help. The issue "workarounded" for existing cassandra 3.11 releases, but cassandra4 should probably default to systemd. > Systemd support for RPM > --- > > Key: CASSANDRA-13148 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13148 > Project: Cassandra > Issue Type: New Feature > Components: Packaging >Reporter: Spiros Ioannou >Priority: Normal > > Since CASSANDRA-12967 will provide an RPM file, it would be greatly > beneficial if this package included systemd startup unit configuration > instead of the current traditional init-based, which misbehaves on > RHEL7/CentOS7. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15901) Force jenkins tests to run on the private VPC IP
[
https://issues.apache.org/jira/browse/CASSANDRA-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146133#comment-17146133
]
Michael Semb Wever commented on CASSANDRA-15901:
Back references:
- example failure stacktrace on
[ci-cassandra.a.o|https://ci-cassandra.apache.org/job/Cassandra-trunk/150/testReport/(root)/_init_/org_apache_cassandra_locator_ReplicaCollectionTest/]
- dev ML
[post|https://lists.apache.org/thread.html/r1a7bc49b0648ec3b4ab9245dc101dc7dfbec51048f83c7128e3989eb%40%3Cdev.cassandra.apache.org%3E]
asking for help
> Force jenkins tests to run on the private VPC IP
>
>
> Key: CASSANDRA-15901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15901
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Many of the ci-cassandra jenkins runs fail on {{ip-10-0-5-5: Name or service
> not known}}. CASSANDRA-15622 addressed some of these but many still remain.
> Currently test C* nodes are either failing or listening on a public ip
> depending on which agent they end up.
> The idea behind this ticket is to make ant force the private VPC ip in the
> cassandra yaml when building, this will force the nodes to listen on the
> correct ip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15901) Force jenkins tests to run on the private VPC IP
[
https://issues.apache.org/jira/browse/CASSANDRA-15901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146130#comment-17146130
]
Michael Semb Wever commented on CASSANDRA-15901:
Quick interjection while i keep looking…
bq. If it does we'd need to run it against eth0 on all agents and see we indeed
get what we expect and tests run ok
Not all the agents are AWS. Some are virtuals on-premise (e.g. iland). In fact
I only know for certain that the Amazon agents are AWS :shrug:
> Force jenkins tests to run on the private VPC IP
>
>
> Key: CASSANDRA-15901
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15901
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Many of the ci-cassandra jenkins runs fail on {{ip-10-0-5-5: Name or service
> not known}}. CASSANDRA-15622 addressed some of these but many still remain.
> Currently test C* nodes are either failing or listening on a public ip
> depending on which agent they end up.
> The idea behind this ticket is to make ant force the private VPC ip in the
> cassandra yaml when building, this will force the nodes to listen on the
> correct ip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15894) JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15894: --- Assignee: Berenguer Blasi > JAVA 8: test_multiple_repair - > repair_tests.incremental_repair_test.TestIncRepair > - > > Key: CASSANDRA-15894 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15894 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > JAVA 8: test_multiple_repair - > repair_tests.incremental_repair_test.TestIncRepair > Fails locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/46515d14-9be4-4edb-8db4-5930312d2bfb/jobs/1329 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15894) JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair
[
https://issues.apache.org/jira/browse/CASSANDRA-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146126#comment-17146126
]
Berenguer Blasi commented on CASSANDRA-15894:
-
Passes locally for me under j8 and looks pretty stable o[n
ci-cassandra|https://ci-cassandra.apache.org/job/Cassandra-trunk/196/testReport/dtest-novnode.repair_tests.incremental_repair_test/TestIncRepair/test_multiple_repair/history/]
{noformat}
pytest --cassandra-dir=/tmp/test
repair_tests/incremental_repair_test.py::TestIncRepair::test_multiple_repair
===
test session starts
===
platform linux -- Python 3.6.9, pytest-3.6.4, py-1.8.1, pluggy-0.7.1
rootdir: /home/bereng/work/repos/bdpWS/dtests, inifile: pytest.ini
plugins: timeout-1.3.4, flaky-3.6.1
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/incremental_repair_test.py .
[100%]
===Flaky Test Report===test_multiple_repair passed 1 out of the required 1
times. Success!===End Flaky Test
Report===
1 passed in 67.34 seconds
{noformat}
> JAVA 8: test_multiple_repair -
> repair_tests.incremental_repair_test.TestIncRepair
> -
>
> Key: CASSANDRA-15894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15894
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> JAVA 8: test_multiple_repair -
> repair_tests.incremental_repair_test.TestIncRepair
> Fails locally and in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/46515d14-9be4-4edb-8db4-5930312d2bfb/jobs/1329
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15894) JAVA 8: test_multiple_repair - repair_tests.incremental_repair_test.TestIncRepair
[ https://issues.apache.org/jira/browse/CASSANDRA-15894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15894: Fix Version/s: 4.0-rc > JAVA 8: test_multiple_repair - > repair_tests.incremental_repair_test.TestIncRepair > - > > Key: CASSANDRA-15894 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15894 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.0-rc > > > JAVA 8: test_multiple_repair - > repair_tests.incremental_repair_test.TestIncRepair > Fails locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/46515d14-9be4-4edb-8db4-5930312d2bfb/jobs/1329 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
[
https://issues.apache.org/jira/browse/CASSANDRA-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146125#comment-17146125
]
Berenguer Blasi commented on CASSANDRA-15893:
-
Passes locally for me as well as the other ones you raised. Under j11:
{noformat}
pytest --cassandra-dir=/tmp/test
consistency_test.py::TestConsistency::test_short_read
===
test session starts
===
platform linux -- Python 3.6.9, pytest-3.6.4, py-1.8.1, pluggy-0.7.1
rootdir: /home/bereng/work/repos/bdpWS/dtests, inifile: pytest.ini
plugins: timeout-1.3.4, flaky-3.6.1
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
consistency_test.py .
[100%]
===Flaky Test Report===test_short_read passed 1 out of the required 1 times.
Success!===End Flaky Test
Report==
1 passed in 710.55 seconds
{noformat}
> JAVA 11: test_short_read - consistency_test.TestConsistency
> ---
>
> Key: CASSANDRA-15893
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15893
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ekaterina Dimitrova
>Priority: Normal
>
> JAVA 11: test_short_read - consistency_test.TestConsistency
> Failing locally and in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15892: Fix Version/s: 4.0-rc > JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild > -- > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
[ https://issues.apache.org/jira/browse/CASSANDRA-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15893: Fix Version/s: 4.0-rc > JAVA 11: test_short_read - consistency_test.TestConsistency > --- > > Key: CASSANDRA-15893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15893 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc > > > JAVA 11: test_short_read - consistency_test.TestConsistency > Failing locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15893) JAVA 11: test_short_read - consistency_test.TestConsistency
[ https://issues.apache.org/jira/browse/CASSANDRA-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15893: --- Assignee: Berenguer Blasi > JAVA 11: test_short_read - consistency_test.TestConsistency > --- > > Key: CASSANDRA-15893 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15893 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > > JAVA 11: test_short_read - consistency_test.TestConsistency > Failing locally and in CircleCI: > https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1337 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[
https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146119#comment-17146119
]
Berenguer Blasi commented on CASSANDRA-15892:
-
[~e.dimitrova] This test doesn't seem to fail on the latest ci-cassandra runs,
also I did run it locally both under j8 and j11 and it passes.
{noformat}
(dtests) bereng@dxpc:~/work/repos/bdpWS/dtests$ pytest
--cassandra-dir=/tmp/test rebuild_test.py::TestRebuild::test_resumable_rebuild
===
test session starts
===
platform linux -- Python 3.6.9, pytest-3.6.4, py-1.8.1, pluggy-0.7.1
rootdir: /home/bereng/work/repos/bdpWS/dtests, inifile: pytest.ini
plugins: timeout-1.3.4, flaky-3.6.1
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
rebuild_test.py .
[100%]
===Flaky Test Report===
test_resumable_rebuild passed 1 out of the required 1 times. Success!
===End Flaky Test Report===
1 passed in 70.18 seconds
(dtests) bereng@dxpc:~/work/repos/bdpWS/dtests$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment (build 11.0.7+10-post-Ubuntu-2ubuntu218.04)
OpenJDK 64-Bit Server VM (build 11.0.7+10-post-Ubuntu-2ubuntu218.04, mixed
mode, sharing)
{noformat}
Can you confirm this is the case for you as well? maybe sthg got fixed in the
last few days
> JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
> --
>
> Key: CASSANDRA-15892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15892
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Ekaterina Dimitrova
>Assignee: Berenguer Blasi
>Priority: Normal
>
> JAVA 11:
> test_resumable_rebuild - rebuild_test.TestRebuild
> Fails locally and in
> [CircleCI |
> [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-15892: Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/dtest Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild > -- > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15892) JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild
[ https://issues.apache.org/jira/browse/CASSANDRA-15892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-15892: --- Assignee: Berenguer Blasi > JAVA 11: test_resumable_rebuild - rebuild_test.TestRebuild > -- > > Key: CASSANDRA-15892 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15892 > Project: Cassandra > Issue Type: Bug >Reporter: Ekaterina Dimitrova >Assignee: Berenguer Blasi >Priority: Normal > > JAVA 11: > test_resumable_rebuild - rebuild_test.TestRebuild > Fails locally and in > [CircleCI | > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/222/workflows/11202c7e-6c94-4d4e-bbbf-9e2fa9791ad0/jobs/1338]] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13524) cassandra core connector - Guava incompatibility: Detected incompatible version of Guava in the classpath. You need 16.0.1 or higher
[
https://issues.apache.org/jira/browse/CASSANDRA-13524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146090#comment-17146090
]
Stuart Meikle commented on CASSANDRA-13524:
---
If you set an issue to resolved could you add a comment about why so others can
follow please?
> cassandra core connector - Guava incompatibility: Detected incompatible
> version of Guava in the classpath. You need 16.0.1 or higher
>
>
> Key: CASSANDRA-13524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13524
> Project: Cassandra
> Issue Type: Bug
>Reporter: Michael Hornung
>Priority: Normal
> Attachments: build.sbt, error_log.txt
>
>
> Hallo,
> with my application I have a AKKA-http microservice which want’s to acess a
> cassandra database table from scala.
> Therefore I included this dependency in SBT:
> "com.datastax.cassandra" % "cassandra-driver-core" % "3.2.0"
> In my scalafile I have this coding:
> --
> ….
> import com.datastax.driver.core.Cluster
> import com.google.common.util.concurrent._
> ….
> val cassandraHost= "localhost"
> val keyStore = "data4service"
> //setup cassandra
> val cluster = {
> Cluster.builder()
> .addContactPoint(cassandraHost)
> .withCredentials("user", "password")
> .build()
> }
> //connect to cassandra keystore
> val session = cluster.connect(keyStore)
> val product = "123e4567-e89b-12d3-a456-426655440003"
> val select = s"SELECT quantity FROM stock WHERE product = $product"
> val result = session.execute(select)
> ….
> --
> During build guava Version 19.0 is downloaded automatically
> Unfortunately if I run my application I get this Error during runtime:
> --
> com.datastax.driver.core.exceptions.DriverInternalError: Detected
> incompatible version of Guava in the classpath. You need 16.0.1 or higher.
> at
> com.datastax.driver.core.GuavaCompatibility.selectImplementation(GuavaCompatibility.java:138)
> at
> com.datastax.driver.core.GuavaCompatibility.(GuavaCompatibility.java:52)
> --
> that is not logical bevause Guava 19.0 is on the system. Can you help me?
> Kind regards,
> Michael
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
