[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429505#comment-17429505
]
Maulin Vasavada commented on CASSANDRA-17031:
-
Hi all
I added an example of K8s PEM based SslContextFactory also in the [PR#
1267|https://github.com/apache/cassandra/pull/1267/files]. After giving some
more thoughts to the Password changes suggestions by Derek, I think it should
be a separate ticket. I've some ideas that I want to discuss and it would be
ideal to have a separate ticket for it.
Thanks
Maulin
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12 keystore for
> private key and the trusted certificates. However, this doesn't impact the
> user of the implementation in anyway and it is mentioned for clarity only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429469#comment-17429469
]
Andres de la Peña edited comment on CASSANDRA-17043 at 10/15/21, 7:43 PM:
--
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for the multiplexer jobs
should be based on the number of repetitions, which defaults to 100.
I think that what we can do is simply use dedicated executors for the
multiplexer jobs, so they can use the same resource class as the original job,
but with a different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The default parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres. This is more or less in line with the previous
values, but I wonder if we should go for higher numbers in lowres and midres.
was (Author: adelapena):
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The default parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres. This is more or less in line with the previous
values, but I wonder if we should go for higher numbers in lowres and midres.
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429469#comment-17429469
]
Andres de la Peña edited comment on CASSANDRA-17043 at 10/15/21, 7:39 PM:
--
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The default parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres. This is more or less in line with the previous
values, but I wonder if we should go for higher numbers in lowres and midres.
was (Author: adelapena):
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The default parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres. This is more or less in line with the previous
values, but I wonder if we should go for higher number in lowres and midres.
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429469#comment-17429469
]
Andres de la Peña edited comment on CASSANDRA-17043 at 10/15/21, 7:38 PM:
--
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The default parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres. This is more or less in line with the previous
values, but I wonder if we should go for higher number in lowres and midres.
was (Author: adelapena):
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The defaults parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres.
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
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-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429469#comment-17429469
]
Andres de la Peña commented on CASSANDRA-17043:
---
I understand that the parallelisms for the regular test jobs are based on the
number of tests in that job, while the parallelism for multiplexer jobs should
be based on the number of repetitions, which defaults to 100.
I think that we can do is simply use dedicated executors for the multiplexer
jobs, so they can use the same resource class as the original job, but with a
different parallelism. I gave it a go in [the branch for
3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0],
and I'll update the other branches if the approach looks good.
The defaults parallelisms for the multiplexer jobs are 4 for lowres, 25 for
midres and 100 for highres.
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
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-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429386#comment-17429386
]
Stefan Miklosovic commented on CASSANDRA-16956:
---
trunk https://github.com/apache/cassandra/pull/1272
4.0 https://github.com/apache/cassandra/pull/1273
[~jmckenzie] would you mind to check again?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429381#comment-17429381 ] Benjamin Lerer commented on CASSANDRA-17027: I agree with doing the work on a separate ticket. > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- 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-16996) Prevent broken concurrent schema read/writes
[
https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429375#comment-17429375
]
Caleb Rackliffe commented on CASSANDRA-16996:
-
With the discussion over how to test this in a better place, I've thrown my +1
(and one more non-controversial nit) on the PR.
I'm still in favor of removing {{testSchemaPullSynchoricity()}}, but I'm fine
leaving a second reviewer ([~jlewandowski]?), which we should probably grab,
given there is concurrency involved here, to break that tie ;)
> Prevent broken concurrent schema read/writes
>
>
> Key: CASSANDRA-16996
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16996
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 3.11.x, 4.0, 4.x
>
>
> See CASSANDRA-16856 where the concurrent read/write path was left out
--
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-16996) Prevent broken concurrent schema read/writes
[ https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16996: Test and Documentation Plan: Patch adds fuzz testing around local schema change atomicity. Status: Patch Available (was: In Progress) > Prevent broken concurrent schema read/writes > > > Key: CASSANDRA-16996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16996 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.11.x, 4.0, 4.x > > > See CASSANDRA-16856 where the concurrent read/write path was left out -- 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-16996) Prevent broken concurrent schema read/writes
[ https://issues.apache.org/jira/browse/CASSANDRA-16996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Caleb Rackliffe updated CASSANDRA-16996: Reviewers: Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Caleb Rackliffe, Caleb Rackliffe (was: Caleb Rackliffe) Status: Review In Progress (was: Patch Available) > Prevent broken concurrent schema read/writes > > > Key: CASSANDRA-16996 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16996 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Schema >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.11.x, 4.0, 4.x > > > See CASSANDRA-16856 where the concurrent read/write path was left out -- 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-17044) Refactor schema management to allow for schema source pluggability
[ https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429366#comment-17429366 ] Caleb Rackliffe commented on CASSANDRA-17044: - Having not even read the patch, it feels like there might be some overlap w/ CASSANDRA-16996, which is probably going to land shortly. > Refactor schema management to allow for schema source pluggability > -- > > Key: CASSANDRA-17044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > The idea is decompose `Schema` into separate entities responsible for > different things. In particular extract what is related to schema storage and > synchronization into a separate class so that it is possible to create an > extension point there and store schema in a different way than > `system_schema` keyspace, for example in etcd. > This would also simplify the logic and reduce the number of special cases, > make all the things more testable and the logic of internal classes > encapsulated. -- 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-17044) Refactor schema management to allow for schema source pluggability
[ https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429355#comment-17429355 ] Jeremiah Jordan commented on CASSANDRA-17044: - A CEP around this is in process, should be ready to propose in the next week. > Refactor schema management to allow for schema source pluggability > -- > > Key: CASSANDRA-17044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > The idea is decompose `Schema` into separate entities responsible for > different things. In particular extract what is related to schema storage and > synchronization into a separate class so that it is possible to create an > extension point there and store schema in a different way than > `system_schema` keyspace, for example in etcd. > This would also simplify the logic and reduce the number of special cases, > make all the things more testable and the logic of internal classes > encapsulated. -- 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-17044) Refactor schema management to allow for schema source pluggability
[ https://issues.apache.org/jira/browse/CASSANDRA-17044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429340#comment-17429340 ] Jacek Lewandowski commented on CASSANDRA-17044: --- https://github.com/apache/cassandra/pull/1270 (cassandra-4.0 - perhaps not needed, but...) https://github.com/apache/cassandra/pull/1271 (trunk) > Refactor schema management to allow for schema source pluggability > -- > > Key: CASSANDRA-17044 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Schema >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > The idea is decompose `Schema` into separate entities responsible for > different things. In particular extract what is related to schema storage and > synchronization into a separate class so that it is possible to create an > extension point there and store schema in a different way than > `system_schema` keyspace, for example in etcd. > This would also simplify the logic and reduce the number of special cases, > make all the things more testable and the logic of internal classes > encapsulated. -- 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-17028) Backport snakeyaml 1.26 upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-17028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17028: - Fix Version/s: (was: 3.11.x) 3.11.12 Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/5c7603c2aed261380e364f5f50933db11038dbb0 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed w/nits fixed, thanks! > Backport snakeyaml 1.26 upgrade > --- > > Key: CASSANDRA-17028 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17028 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.12 > > > In CASSANDRA-16150 snakeyaml was upgraded, but only in the 4.0 line. We > should backport this to 3.11 and 3.0 as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit f646a7c312ac2775ce71350e1a1b70820dce74a4 Merge: 25f67a7 5c7603c Author: Brandon Williams AuthorDate: Fri Oct 15 10:07:21 2021 -0500 Merge branch 'cassandra-3.11' into cassandra-4.0 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (25f67a7 -> f646a7c)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 25f67a7 Merge branch 'cassandra-3.11' into cassandra-4.0 new 5c7603c Upgrade to snakeyaml 1.26 new f646a7c Merge branch 'cassandra-3.11' into cassandra-4.0 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (d9ca614 -> 5a88bc8)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d9ca614 Merge branch 'cassandra-4.0' into trunk new 5c7603c Upgrade to snakeyaml 1.26 new f646a7c Merge branch 'cassandra-3.11' into cassandra-4.0 new 5a88bc8 Merge branch 'cassandra-4.0' into trunk The 3 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated: Upgrade to snakeyaml 1.26
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.11 by this push:
new 5c7603c Upgrade to snakeyaml 1.26
5c7603c is described below
commit 5c7603c2aed261380e364f5f50933db11038dbb0
Author: Brandon Williams
AuthorDate: Fri Oct 8 12:01:40 2021 -0500
Upgrade to snakeyaml 1.26
Patch by brandonwilliams; reviewed by bereng for CASSANDRA-17028
---
CHANGES.txt| 1 +
build.xml | 2 +-
.../cassandra/config/YamlConfigurationLoader.java | 30 ++
3 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 3f0957c..8460705 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.11.12
+ * Upgrade snakeyaml to 1.26 in 3.11 (CASSANDRA=17028)
* 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)
diff --git a/build.xml b/build.xml
index fe77098..f2b60eb 100644
--- a/build.xml
+++ b/build.xml
@@ -360,7 +360,7 @@
-
+
diff --git a/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java
b/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java
index 1dedb29..e193080 100644
--- a/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java
+++ b/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java
@@ -17,12 +17,13 @@
*/
package org.apache.cassandra.config;
-import java.beans.IntrospectionException;
import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
+import java.lang.annotation.Annotation;
import java.net.URL;
+import java.util.Collections;
import java.util.HashSet;
import java.util.List;
@@ -120,7 +121,8 @@ public class YamlConfigurationLoader implements
ConfigurationLoader
throw new AssertionError(e);
}
-Constructor constructor = new CustomConstructor(Config.class,
Config.class.getClassLoader());
+
+Constructor constructor = new CustomConstructor(Config.class,
Yaml.class.getClassLoader());
PropertiesChecker propertiesChecker = new PropertiesChecker();
constructor.setPropertyUtils(propertiesChecker);
Yaml yaml = new Yaml(constructor);
@@ -180,7 +182,7 @@ public class YamlConfigurationLoader implements
ConfigurationLoader
}
@Override
-protected Map createDefaultMap()
+protected Map createDefaultMap(int initSize)
{
return Maps.newConcurrentMap();
}
@@ -190,15 +192,9 @@ public class YamlConfigurationLoader implements
ConfigurationLoader
{
return Sets.newConcurrentHashSet();
}
-
-@Override
-protected Set createDefaultSet()
-{
-return Sets.newConcurrentHashSet();
-}
}
-private Config loadConfig(Yaml yaml, byte[] configBytes)
+private static Config loadConfig(Yaml yaml, byte[] configBytes)
{
Config config = yaml.loadAs(new ByteArrayInputStream(configBytes),
Config.class);
// If the configuration file is empty yaml will return null. In this
case we should use the default
@@ -222,7 +218,7 @@ public class YamlConfigurationLoader implements
ConfigurationLoader
}
@Override
-public Property getProperty(Class type, String name)
throws IntrospectionException
+public Property getProperty(Class type, String name)
{
final Property result = super.getProperty(type, name);
@@ -254,6 +250,18 @@ public class YamlConfigurationLoader implements
ConfigurationLoader
{
return result.get(object);
}
+
+@Override
+public List getAnnotations()
+{
+return Collections.EMPTY_LIST;
+}
+
+@Override
+public A getAnnotation(Class aClass)
+{
+return null;
+}
};
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5a88bc8cd14c849850718d646e8c7c404e2f1e89 Merge: d9ca614 f646a7c Author: Brandon Williams AuthorDate: Fri Oct 15 10:07:40 2021 -0500 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429299#comment-17429299
]
Andres de la Peña edited comment on CASSANDRA-17043 at 10/15/21, 3:04 PM:
--
Oh, I totally forgot about the multiplexer jobs for upgrade tests! I understand
that those jobs should use exactly the same resource class as the equivalent
job for regular upgrade tests. I have updated the patches and config files to
use the same executors as the corresponding jobs:
||Branch||CI||
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1040/workflows/cd94b8ee-16ee-4e03-85d7-b51c0ede30ac]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:17043-3.11]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1041/workflows/60cfc2c6-1b87-4eca-bf0c-a76326741160]|
|[4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...adelapena:17043-4.0]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1037/workflows/3c412ef8-0e16-48f7-bd8c-5812ccbbcf12]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1037/workflows/f96639ad-e952-4727-90bf-a0228691bc50]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:17043-trunk]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1036/workflows/3e2b79da-609c-44e9-afd5-6337e429a0bc]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1036/workflows/eb1225b6-957d-446c-8b4f-8f6fea6b557b]|
However those executors have a quite low parallelism, which might be enough for
running the relatively small set of regular upgrade jobs but that can be too
low for the repeated runs of a specific test. Perhaps the multiplexer jobs
should use separate, dedicated executors with the same resource class and more
parallelism? Or could we just increase the parallelism of the current
executors? wdyt?
was (Author: adelapena):
Oh, I totally forgot about the multiplexer jobs for upgrade tests! I understand
that those jobs should use exactly the same resource class as the equivalent
job for regular upgrade tests. I have updated the patches and config files to
use the same executors as the corresponding jobs:
||Branch||
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:17043-3.11]|
|[4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...adelapena:17043-4.0]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:17043-trunk]|
However those executors have a quite low parallelism, which might be enough for
running the relatively small set of regular upgrade jobs but that can be too
low for the repeated runs of a specific test. Perhaps the multiplexer jobs
should use separate, dedicated executors with the same resource class and more
parallelism? Or could we just increase the parallelism of the current
executors? wdyt?
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands,
[jira] [Commented] (CASSANDRA-17043) CircleCI dtest multiplexer with MIDRES needs more resources
[
https://issues.apache.org/jira/browse/CASSANDRA-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429299#comment-17429299
]
Andres de la Peña commented on CASSANDRA-17043:
---
Oh, I totally forgot about the multiplexer jobs for upgrade tests! I understand
that those jobs should use exactly the same resource class as the equivalent
job for regular upgrade tests. I have updated the patches and config files to
use the same executors as the corresponding jobs:
||Branch||
|[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...adelapena:17043-3.0]|
|[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...adelapena:17043-3.11]|
|[4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...adelapena:17043-4.0]|
|[trunk|https://github.com/apache/cassandra/compare/trunk...adelapena:17043-trunk]|
However those executors have a quite low parallelism, which might be enough for
running the relatively small set of regular upgrade jobs but that can be too
low for the repeated runs of a specific test. Perhaps the multiplexer jobs
should use separate, dedicated executors with the same resource class and more
parallelism? Or could we just increase the parallelism of the current
executors? wdyt?
> CircleCI dtest multiplexer with MIDRES needs more resources
> ---
>
> Key: CASSANDRA-17043
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17043
> Project: Cassandra
> Issue Type: Task
> Components: CI
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Low
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The CircleCI jobs for regular dtests jobs have more resources in MIDRES,
> which is necessary for some dtests to reliably success. However, the dtest
> multiplexer uses the same resources for LOWRES and MIDRES.
> I think that the dtest multiplexer should always use the same resources as
> the regular dtests. Using too small resources in the multiplexer can lead to
> failures that don't reproduce in the regular dtest jobs, like the one we
> found in
> [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> when trying to repeatedly run a resource-hungry dtest, or like [this other
> one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422]
> while running {{test_network_topology}}.
> This happens because I forgot to update the diff patch when adding the
> multiplexer. This doesn't affect HIGHRES because in that case the patch
> changes the configuration of the test executor, while in MIDRES a new
> executor is defined.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17045) Add minor upgrade/downgrade/mixed mode support in in-jvm dtests
Marcus Eriksson created CASSANDRA-17045: --- Summary: Add minor upgrade/downgrade/mixed mode support in in-jvm dtests Key: CASSANDRA-17045 URL: https://issues.apache.org/jira/browse/CASSANDRA-17045 Project: Cassandra Issue Type: Improvement Reporter: Marcus Eriksson It should be possible to write in-jvm dtests where we upgrade from an earlier minor version to the current one, and since we support downgrading between minors we should add some tests for that. If possible it would be nice to provide a new test target running all the in-jvm dtests, but where some random nodes in the in-jvm clusters are running a previous minor version to exercise a mixed mode cluster. Goal is to be able to catch issues like CASSANDRA-17042 early. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429289#comment-17429289 ] Ekaterina Dimitrova edited comment on CASSANDRA-17027 at 10/15/21, 1:43 PM: I think what was suggested makes sense and I am all in. Whether it should be in this ticket or not, I don't have strong preference in general as soon as we keep the CQLTester improvements in a separate commit from the main body of work in this ticket. On the other hand, if there are a few tickets working in that area it might be a good idea to keep the things incremental and push things one by one, not blocking anything. We can actually even push one commit as phase 1 and continue working on the other commit as part of phase 2 in the same ticket. I will leave this to you to decide how you want to organize the flow, just giving ideas. :) Otherwise, the suggestions make total sense to me. was (Author: e.dimitrova): I think what was suggested makes sense and I am all in. Whether it should be in this ticket or not, I don't have strong preference in general as soon as we keep the CQLTester improvements in a separate commit from the main body of work in this ticket. On the other hand, if there are a few tickets working in that area it might be a good idea to keep the things incremental and push things one by one, not blocking anything. We can actually even push one commit as phase 1 and continue working on the other commit as part of phase 2 in the same ticket. I will leave this to you to decide how you want to organize the flow. Otherwise, the suggestions make total sense to me. > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429289#comment-17429289 ] Ekaterina Dimitrova edited comment on CASSANDRA-17027 at 10/15/21, 1:42 PM: I think what was suggested makes sense and I am all in. Whether it should be in this ticket or not, I don't have strong preference in general as soon as we keep the CQLTester improvements in a separate commit from the main body of work in this ticket. On the other hand, if there are a few tickets working in that area it might be a good idea to keep the things incremental and push things one by one, not blocking anything. We can actually even push one commit as phase 1 and continue working on the other commit as part of phase 2 in the same ticket. I will leave this to you to decide how you want to organize the flow. Otherwise, the suggestions make total sense to me. was (Author: e.dimitrova): I think what was suggested makes sense and I am all in. Whether it should be in this ticket or not, I don't have strong preference in general as soon as we keep the CQLTester improvements in a separate commit from the main body of work in this ticket. On the other hand, if there are a few tickets working in that area it might be a good idea to keep the things incremental and push things one by one. We can actually even push one commit as phase 1 and continue working on the other commit as part of phase 2 in the same ticket. I will leave this to you to decide how you want to organize the flow. Otherwise, the suggestions make total sense to me. > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- 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-17027) Allow to grant permission for all tables in a keyspace
[ https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429289#comment-17429289 ] Ekaterina Dimitrova commented on CASSANDRA-17027: - I think what was suggested makes sense and I am all in. Whether it should be in this ticket or not, I don't have strong preference in general as soon as we keep the CQLTester improvements in a separate commit from the main body of work in this ticket. On the other hand, if there are a few tickets working in that area it might be a good idea to keep the things incremental and push things one by one. We can actually even push one commit as phase 1 and continue working on the other commit as part of phase 2 in the same ticket. I will leave this to you to decide how you want to organize the flow. Otherwise, the suggestions make total sense to me. > Allow to grant permission for all tables in a keyspace > --- > > Key: CASSANDRA-17027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17027 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Syntax, Feature/Authorization >Reporter: Benjamin Lerer >Assignee: Benjamin Lerer >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 10m > Remaining Estimate: 0h > > In some scenario it is useful to prevent users to alter or drop a keyspace > while allowing them to create new tables and user types. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17044) Refactor schema management to allow for schema source pluggability
Jacek Lewandowski created CASSANDRA-17044: - Summary: Refactor schema management to allow for schema source pluggability Key: CASSANDRA-17044 URL: https://issues.apache.org/jira/browse/CASSANDRA-17044 Project: Cassandra Issue Type: Improvement Components: Cluster/Schema Reporter: Jacek Lewandowski Assignee: Jacek Lewandowski The idea is decompose `Schema` into separate entities responsible for different things. In particular extract what is related to schema storage and synchronization into a separate class so that it is possible to create an extension point there and store schema in a different way than `system_schema` keyspace, for example in etcd. This would also simplify the logic and reduce the number of special cases, make all the things more testable and the logic of internal classes encapsulated. -- 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-10303) streaming for 'nodetool rebuild' fails after adding a datacenter
[
https://issues.apache.org/jira/browse/CASSANDRA-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-10303:
Assignee: Yuki Morishita
> streaming for 'nodetool rebuild' fails after adding a datacenter
> -
>
> Key: CASSANDRA-10303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10303
> Project: Cassandra
> Issue Type: Bug
> Environment: jdk1.7
> cassandra 2.1.8
>Reporter: zhaoyan
>Assignee: Yuki Morishita
>Priority: Normal
>
> we add another datacenter.
> use nodetool rebuild DC1
> stream from some node of old datacenter always hang up with these exception:
> {code}
> ERROR [Thread-1472] 2015-09-10 19:24:53,091 CassandraDaemon.java:223 -
> Exception in thread Thread[Thread-1472,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Connection timed out
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.7.0_60]
> Caused by: java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
> at sun.nio.ch.IOUtil.read(IOUtil.java:197) ~[na:1.7.0_60]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:59)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> ~[na:1.7.0_60]
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> ~[na:1.7.0_60]
> at
> org.apache.cassandra.streaming.compress.CompressedInputStream$Reader.runMayThrow(CompressedInputStream.java:172)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> ~[apache-cassandra-2.1.8.jar:2.1.8]
> ... 1 common frames omitted
> {code}
> i must restart node to stop current rebuild, and rebuild agagin and again to
> success
--
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-17027) Allow to grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429225#comment-17429225
]
Andres de la Peña commented on CASSANDRA-17027:
---
Having a single per-test keyspace probably makes more sense to keep thing
simple. I have also been missing a {{createKeyspace}} method. Those changes
seem quite more involved because they would affect a lot of tests, so I think
we should explore those {{CQLTester}} improvements in a separate ticket and not
block this ticket, nor CASSANDRA-16902, wdyt?
> Allow to grant permission for all tables in a keyspace
> ---
>
> Key: CASSANDRA-17027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17027
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/Authorization
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In some scenario it is useful to prevent users to alter or drop a keyspace
> while allowing them to create new tables and user types.
--
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-15433) Pending ranges are not recalculated on keyspace creation
[
https://issues.apache.org/jira/browse/CASSANDRA-15433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Petrov updated CASSANDRA-15433:
Fix Version/s: 4.1
4.0.2
3.11.12
3.0.26
Source Control Link:
https://github.com/apache/cassandra/commit/11af037fd99bfb4a942f7d7dd55c177a37d29f63
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Pending ranges are not recalculated on keyspace creation
>
>
> Key: CASSANDRA-15433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15433
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1
>
>
> When a node begins bootstrapping, Cassandra recalculates pending tokens for
> each keyspace that exists when the state change is observed (in
> StorageService:handleState*). When new keyspaces are created, we do not
> recalculate pending ranges (around Schema:merge). As a result, writes for new
> keyspaces are not received by nodes in BOOT or BOOT_REPLACE modes. When
> bootstrapping finishes, the node which just bootstrapped will not have data
> for the newly created keyspace.
> Consider a ring with bootstrapped nodes A, B, and C. Node D is pending, and
> when it finishes bootstrapping, C will cede ownership of some ranges to D. A
> quorum write is acknowledged by C and A. B missed the write, and the
> coordinator didn't send it to D at all. When D finishes bootstrapping, the
> quorum B+D will not contain the mutation.
> Steps to reproduce:
> # Join a node in BOOT mode
> # Create a keyspace
> # Send writes to that keyspace
> # On the joining node, observe that {{nodetool cfstats}} records zero writes
> to the new keyspace
> I have observed this directly in Cassandra 3.0, and based on my reading the
> code, I believe it affects up through trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15433) Pending ranges are not recalculated on keyspace creation
[
https://issues.apache.org/jira/browse/CASSANDRA-15433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429206#comment-17429206
]
Alex Petrov commented on CASSANDRA-15433:
-
Committed to 3.0 with
[11af037fd99bfb4a942f7d7dd55c177a37d29f63|https://github.com/apache/cassandra/commit/11af037fd99bfb4a942f7d7dd55c177a37d29f63]
and merged up to
[3.11|https://github.com/apache/cassandra/commit/610d5d4eb5205cd4ca2f573237da14db055757c1],
[4.0|https://github.com/apache/cassandra/commit/25f67a75e22fdd9bdabd4b17dd0e11973ce59c2d]
and
[trunk|https://github.com/apache/cassandra/commit/d9ca61404334f3bd94c08cf66ccd15e8c5287f52].
> Pending ranges are not recalculated on keyspace creation
>
>
> Key: CASSANDRA-15433
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15433
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Membership
>Reporter: Josh Snyder
>Assignee: Sumanth Pasupuleti
>Priority: Normal
>
> When a node begins bootstrapping, Cassandra recalculates pending tokens for
> each keyspace that exists when the state change is observed (in
> StorageService:handleState*). When new keyspaces are created, we do not
> recalculate pending ranges (around Schema:merge). As a result, writes for new
> keyspaces are not received by nodes in BOOT or BOOT_REPLACE modes. When
> bootstrapping finishes, the node which just bootstrapped will not have data
> for the newly created keyspace.
> Consider a ring with bootstrapped nodes A, B, and C. Node D is pending, and
> when it finishes bootstrapping, C will cede ownership of some ranges to D. A
> quorum write is acknowledged by C and A. B missed the write, and the
> coordinator didn't send it to D at all. When D finishes bootstrapping, the
> quorum B+D will not contain the mutation.
> Steps to reproduce:
> # Join a node in BOOT mode
> # Create a keyspace
> # Send writes to that keyspace
> # On the joining node, observe that {{nodetool cfstats}} records zero writes
> to the new keyspace
> I have observed this directly in Cassandra 3.0, and based on my reading the
> code, I believe it affects up through trunk.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (84eb1b8 -> 11af037)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 84eb1b8 Log more information when a node runs out of commitlog space
add 11af037 Add blocking pendingranges calculation when keyspace is added
No new revisions were added by this update.
Summary of changes:
.../org/apache/cassandra/gms/VersionedValue.java | 7 +
.../apache/cassandra/schema/SchemaKeyspace.java| 9 ++
.../cassandra/distributed/action/GossipHelper.java | 142 +
.../distributed/action/InstanceAction.java | 13 +-
...ception.java => VersionedApplicationState.java} | 15 ++-
.../cassandra/distributed/test/BootstrapTest.java | 38 +-
6 files changed, 206 insertions(+), 18 deletions(-)
create mode 100644
test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java
copy src/java/org/apache/cassandra/io/util/BytesReadTracker.java =>
test/distributed/org/apache/cassandra/distributed/action/InstanceAction.java
(78%)
copy
test/distributed/org/apache/cassandra/distributed/shared/{ShutdownException.java
=> VersionedApplicationState.java} (69%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (be1684b -> 25f67a7)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from be1684b Merge branch cassandra-3.11 into cassandra-4.0 add 11af037 Add blocking pendingranges calculation when keyspace is added add 610d5d4 Merge branch 'cassandra-3.0' into cassandra-3.11 add 25f67a7 Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: src/java/org/apache/cassandra/schema/Schema.java | 8 +++ .../distributed/test/ring/BootstrapTest.java | 25 ++ 2 files changed, 33 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (6411b44 -> 610d5d4)
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a change to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git.
from 6411b44 Merge branch cassandra-3.0 into cassandra-3.11
add 11af037 Add blocking pendingranges calculation when keyspace is added
add 610d5d4 Merge branch 'cassandra-3.0' into cassandra-3.11
No new revisions were added by this update.
Summary of changes:
.../org/apache/cassandra/gms/VersionedValue.java | 6 +
.../apache/cassandra/schema/SchemaKeyspace.java| 10 ++
.../cassandra/distributed/action/GossipHelper.java | 142 +
.../distributed/action/InstanceAction.java | 13 +-
...ception.java => VersionedApplicationState.java} | 15 ++-
.../cassandra/distributed/test/BootstrapTest.java | 38 +-
6 files changed, 206 insertions(+), 18 deletions(-)
create mode 100644
test/distributed/org/apache/cassandra/distributed/action/GossipHelper.java
copy src/java/org/apache/cassandra/io/util/BytesReadTracker.java =>
test/distributed/org/apache/cassandra/distributed/action/InstanceAction.java
(78%)
copy
test/distributed/org/apache/cassandra/distributed/shared/{ShutdownException.java
=> VersionedApplicationState.java} (69%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d9ca61404334f3bd94c08cf66ccd15e8c5287f52 Merge: ebce74e 25f67a7 Author: Alex Petrov AuthorDate: Fri Oct 15 11:27:39 2021 +0200 Merge branch 'cassandra-4.0' into trunk src/java/org/apache/cassandra/schema/Schema.java | 8 +++ .../distributed/test/ring/BootstrapTest.java | 25 ++ 2 files changed, 33 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (ebce74e -> d9ca614)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ebce74e Merge branch cassandra-4.0 into trunk add 11af037 Add blocking pendingranges calculation when keyspace is added add 610d5d4 Merge branch 'cassandra-3.0' into cassandra-3.11 add 25f67a7 Merge branch 'cassandra-3.11' into cassandra-4.0 new d9ca614 Merge branch 'cassandra-4.0' into trunk 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: src/java/org/apache/cassandra/schema/Schema.java | 8 +++ .../distributed/test/ring/BootstrapTest.java | 25 ++ 2 files changed, 33 insertions(+) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429203#comment-17429203
]
Yuqi Gu commented on CASSANDRA-17040:
-
The unit tests log was attched.(UTs_2).
All test cases were passed except one :
{code:java}
[junit-timeout] Forked Java VM exited abnormally. Please note the time in the
report does not reflect the time until the VM exit.
{code}
It seems to be related to my loacal JVM issues.
Anyway, the patch of upgrading snappy-java was verified by unit tests.
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
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-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuqi Gu updated CASSANDRA-17040:
Attachment: UTs_2.txt
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt, UTs_2.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
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-17027) Allow to grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429194#comment-17429194
]
Benjamin Lerer commented on CASSANDRA-17027:
I believe that we should also have a mechanism similar to {{createTable}} and
{{currentTable}} with {{createKeyspace}} so that people automatically use the
keyspace they last created by default.
> Allow to grant permission for all tables in a keyspace
> ---
>
> Key: CASSANDRA-17027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17027
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/Authorization
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In some scenario it is useful to prevent users to alter or drop a keyspace
> while allowing them to create new tables and user types.
--
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-17027) Allow to grant permission for all tables in a keyspace
[
https://issues.apache.org/jira/browse/CASSANDRA-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429189#comment-17429189
]
Benjamin Lerer commented on CASSANDRA-17027:
I have been wondering for sometime if we should not simply unify things a bit
in {{CQLTester}}. I have not check in details but I do not think that there is
a good reason for having a keyspace re-used across tests considering that we
deleted its content after every test. Dropping and recreating {{KEYSPACE}}
between test is probaly a simpler option and we allow us to get ride of all the
cleaning code and of the logic surrounding {{KEYSPACE_PER_TEST}}.
What do you think?
> Allow to grant permission for all tables in a keyspace
> ---
>
> Key: CASSANDRA-17027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17027
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax, Feature/Authorization
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> In some scenario it is useful to prevent users to alter or drop a keyspace
> while allowing them to create new tables and user types.
--
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-17040) Upgrade Snappy version to support Apple M1
[
https://issues.apache.org/jira/browse/CASSANDRA-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429154#comment-17429154
]
Stefan Miklosovic commented on CASSANDRA-17040:
---
I have run OWASP dependency check against this library version by "ant
dependency-check" and it has not found any security vulnerabilities.
> Upgrade Snappy version to support Apple M1
> --
>
> Key: CASSANDRA-17040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17040
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Compression
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Normal
> Fix For: 4.1
>
> Attachments: UTs.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some Unit test cases were failed in Apple M1:
>
> {code:java}
> [junit-timeout] Testcase:
> testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest):
> Caused an ERROR
> [junit-timeout] SnappyCompressor.create() threw an error:
> java.lang.NoClassDefFoundError Could not initialize class
> org.xerial.snappy.Snappy
> [junit-timeout] org.apache.cassandra.exceptions.ConfigurationException:
> SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError
> Could not initialize class org.xerial.snappy.Snappy
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.(CompressionParams.java:211)
> [junit-timeout] at
> org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
> [junit-timeout] at
> org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
> [junit-timeout] at
>
> ...
> ..
>
> {code}
>
> Snappy-java added M1 support since
> 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]
> So let's upgrade snappy-java dependency to the latest release 1.1.8.4.
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: updated owasp dependency check to 6.4.1 containing rate limiting workarounds
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new 357f58b updated owasp dependency check to 6.4.1 containing rate
limiting workarounds
357f58b is described below
commit 357f58b6def01a7d9b3120b5e6b2798a09666e51
Author: Stefan Miklosovic
AuthorDate: Fri Oct 15 09:30:19 2021 +0200
updated owasp dependency check to 6.4.1 containing rate limiting workarounds
---
build-scripts/cassandra-artifacts.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/build-scripts/cassandra-artifacts.sh
b/build-scripts/cassandra-artifacts.sh
index a807a41..0e51778 100755
--- a/build-scripts/cassandra-artifacts.sh
+++ b/build-scripts/cassandra-artifacts.sh
@@ -50,10 +50,10 @@ set +e # disable immediate exit from this point
ARTIFACTS_BUILD_RUN=0
ECLIPSE_WARNINGS_RUN=0
-#HAS_DEPENDENCY_CHECK_TARGET=$(ant -p build.xml | grep "dependency-check " |
wc -l)
-# OWASP dep checs are unstable in Jenkins, we are getting 503 errors every now
and then from NIST CVE database
-HAS_DEPENDENCY_CHECK_TARGET=0
-DEPENDENCY_CHECK_VERSION=6.3.2
+HAS_DEPENDENCY_CHECK_TARGET=$(ant -p build.xml | grep "dependency-check " | wc
-l)
+# versions starting from 6.4.1 contain "rate limiter" functionality to make
builds more stable
+# https://github.com/jeremylong/DependencyCheck/pull/3725
+DEPENDENCY_CHECK_VERSION=6.4.1
for x in $(seq 1 3); do
if [ "${ARTIFACTS_BUILD_RUN}" -eq "0" ]; then
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14612) Please add OWASP Dependency Check to the build (pom.xml)
[ https://issues.apache.org/jira/browse/CASSANDRA-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429147#comment-17429147 ] Stefan Miklosovic commented on CASSANDRA-14612: --- Dependency check project added "rate limiter" functionality in 6.4.1 which was released like two days ago as we were not the only ones who were hitting this issue. I am going to re-enable checks in cassandra-builds again to see if it improved things. https://github.com/jeremylong/DependencyCheck/pull/3725 > Please add OWASP Dependency Check to the build (pom.xml) > > > Key: CASSANDRA-14612 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14612 > Project: Cassandra > Issue Type: New Feature > Components: Build > Environment: All development, build, test, environments. >Reporter: Albert Baker >Assignee: Stefan Miklosovic >Priority: Normal > Labels: build, security > Fix For: 3.0.26, 3.11.12, 4.0.2, 4.1 > > Original Estimate: 1h > Time Spent: 20m > Remaining Estimate: 40m > > Please add OWASP Dependency Check to the build (pom.xml). OWASP DC makes an > outbound REST call to MITRE Common Vulnerabilities & Exposures (CVE) to > perform a lookup for each dependant .jar to list any/all known > vulnerabilities for each jar. This step is needed because a manual MITRE CVE > lookup/check on the main component does not include checking for > vulnerabilities in components or in dependant libraries. > OWASP Dependency check : > https://www.owasp.org/index.php/OWASP_Dependency_Check has plug-ins for most > Java build/make types (ant, maven, ivy, gradle). > Also, add the appropriate command to the nightly build to generate a report > of all known vulnerabilities in any/all third party libraries/dependencies > that get pulled in. example : mvn -Powasp -Dtest=false -DfailIfNoTests=false > clean aggregate > Generating this report nightly/weekly will help inform the project's > development team if any dependant libraries have a reported known > vulnerailities. Project teams that keep up with removing vulnerabilities on a > weekly basis will help protect businesses that rely on these open source > componets. -- 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-17042) Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-17042:
Test and Documentation Plan: jvm dtest, cci run
Status: Patch Available (was: Open)
* make sure we never rewrite a future stats metadata file
* import should fail on future sstables
* we should fall back to regular streaming if remote node does not support the
current sstable version
https://app.circleci.com/pipelines/github/krummas/cassandra?branch=marcuse%2F17042
https://github.com/apache/cassandra/compare/cassandra-4.0...krummas:marcuse/17042?expand=1
note that the jvm dtest added requires support for minor upgrades in jvm
dtests, will work on that
> Avoid sstable corruption when upgrading from 4.0-rc1 to 4.0.0
> -
>
> Key: CASSANDRA-17042
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17042
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming, Local/SSTable
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> 4.0-rc2 introduced a new sstable version ({{-nb-}}), adding a field in
> {{StatsMetadata}}. When zero copy streaming a file from 4.0-rc2+ to 4.0-rc1,
> the rc1 node will write it as an {{-nb-}} file, mutate the metadata to clear
> repairedAt/level information from StatsMetadata and rewrite the file, keeping
> the same file name. Problem is that since rc1 doesn't know about the new
> field in StatsMetadata, it will write the file without the new StatsMetadata
> field, but with an {{-nb-}} filename. Then, when upgrading this node to rc2+
> we will try to read it as a {{-nb-}} file, but will get {{EOFException}}
> since it doesn't contain the new field.
> We should make sure that we never do zero-copy streaming to nodes that don't
> know about the file version.
> The corrupt sstables can be fixed by simply renaming all components of it to
> {{-na-}} from {{-nb-}}
--
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
