[jira] [Updated] (CASSANDRA-17502) Security enforcement by enabling "two-person concept" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Summary: Security enforcement by enabling "two-person concept"
authorization (was: Security enforcement by enabling "two-man rule"
authorization)
> Security enforcement by enabling "two-person concept" authorization
> ---
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the role, but it would need at least two
> of them (as defined by GRANTORS) to do so to allow the user to actually
> access the data.
> Thus,
> {code}
> GRANT patientdata_access TO doctor_house;
> {code}
> must be conducted by at least two different admin_guys of the available ones
> above.
> When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515085#comment-17515085
]
Berenguer Blasi commented on CASSANDRA-10537:
-
[~Antoine Rocheteau] so the latest stretch would be to:
- Add autocompletion + tests
- Add docs (search for .adoc files)
- Add en entry to CHANGES.txt
- Last rebase and if CI is good I'll merge this for you
We're almost there :-) Feel free to ask for help if you need anything.
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17494) Pre hashed passwords in CQL docs
[ https://issues.apache.org/jira/browse/CASSANDRA-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515083#comment-17515083 ] Berenguer Blasi commented on CASSANDRA-17494: - Thx [~adelapena]! > Pre hashed passwords in CQL docs > > > Key: CASSANDRA-17494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17494 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > CASSANDRA-17334 needs some docs -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17479) WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
[
https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515079#comment-17515079
]
Erick Ramirez commented on CASSANDRA-17479:
---
I've completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch 'asf-site' set up to track remote branch 'asf-site' from 'origin'.
Switched to a new branch 'asf-site'
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 428fdd55 generate docs for 7855f251
$ git push -f origin asf-site
Username for 'https://github.com': erickramirezau
Password for 'https://erickramire...@github.com':
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ 841cb1aa...428fdd55 asf-site -> asf-site (forced update){noformat}
The post is now live in production –
https://cassandra.apache.org/_/case-studies/Kinetic-Data.html
> WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
>
>
> Key: CASSANDRA-17479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17479
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png
>
>
> This ticket is to capture the work associated with adding a new case study to
> the website and entry on the Case Studies page.
> * Add Kinetic Data case study
> * Add Kinetic Data card to Case Studies page
> * Add Kinetic Data logo to images: kinetic_data.svg
> * Fix Backblaze case study typo
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (841cb1a -> 428fdd5)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard 841cb1a generate docs for 4e816112
add 7855f25 Add Kinetic Data to Case Studies, fix Backblaze
add 428fdd5 generate docs for 7855f251
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (841cb1a)
\
N -- N -- N refs/heads/asf-site (428fdd5)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
content/_/_images/companies/kinetic_data.svg | 22 +
...ra-to-deliver-workflow-automation-solution.html | 2 +-
content/_/case-studies.html| 28 +-
.../Kinetic-Data.html} | 108 ++---
content/_/case-studies/backblaze.html | 2 +-
content/search-index.js| 2 +-
.../modules/ROOT/images/companies/kinetic_data.svg | 22 +
.../source/modules/ROOT/pages/case-studies.adoc| 25 -
.../ROOT/pages/case-studies/Kinetic-Data.adoc | 51 ++
.../modules/ROOT/pages/case-studies/backblaze.adoc | 2 +-
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
11 files changed, 200 insertions(+), 64 deletions(-)
create mode 100644 content/_/_images/companies/kinetic_data.svg
copy content/_/{blog/Join-Apache-Cassandras-GSoC-Program-2022.html =>
case-studies/Kinetic-Data.html} (65%)
create mode 100644
site-content/source/modules/ROOT/images/companies/kinetic_data.svg
create mode 100644
site-content/source/modules/ROOT/pages/case-studies/Kinetic-Data.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17479) WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
[
https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515076#comment-17515076
]
Erick Ramirez commented on CASSANDRA-17479:
---
Staging build completed:
||Branch||PR||Commit||Build||
|{{trunk}}|[#115|https://github.com/apache/cassandra-website/pull/115]|[7855f25|https://github.com/apache/cassandra-website/commit/7855f251453642df2f1858523049c911e2da34ce]|[#170|https://ci-cassandra.apache.org/job/cassandra-website/170/]|
The page is now visible in staging --
https://cassandra.staged.apache.org/_/case-studies/Kinetic-Data.html.
> WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
>
>
> Key: CASSANDRA-17479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17479
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png
>
>
> This ticket is to capture the work associated with adding a new case study to
> the website and entry on the Case Studies page.
> * Add Kinetic Data case study
> * Add Kinetic Data card to Case Studies page
> * Add Kinetic Data logo to images: kinetic_data.svg
> * Fix Backblaze case study typo
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (841cb1a -> 428fdd5)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
omit 841cb1a generate docs for 4e816112
add 7855f25 Add Kinetic Data to Case Studies, fix Backblaze
new 428fdd5 generate docs for 7855f251
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (841cb1a)
\
N -- N -- N refs/heads/asf-staging (428fdd5)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
content/_/_images/companies/kinetic_data.svg | 22 +
...ra-to-deliver-workflow-automation-solution.html | 2 +-
content/_/case-studies.html| 28 +-
.../Kinetic-Data.html} | 108 ++---
content/_/case-studies/backblaze.html | 2 +-
content/search-index.js| 2 +-
.../modules/ROOT/images/companies/kinetic_data.svg | 22 +
.../source/modules/ROOT/pages/case-studies.adoc| 25 -
.../ROOT/pages/case-studies/Kinetic-Data.adoc | 51 ++
.../modules/ROOT/pages/case-studies/backblaze.adoc | 2 +-
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
11 files changed, 200 insertions(+), 64 deletions(-)
create mode 100644 content/_/_images/companies/kinetic_data.svg
copy content/_/{blog/Join-Apache-Cassandras-GSoC-Program-2022.html =>
case-studies/Kinetic-Data.html} (65%)
create mode 100644
site-content/source/modules/ROOT/images/companies/kinetic_data.svg
create mode 100644
site-content/source/modules/ROOT/pages/case-studies/Kinetic-Data.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
[
https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17479:
--
Fix Version/s: 4.0.3
(was: NA)
Source Control Link:
https://github.com/apache/cassandra-website/commit/7855f251453642df2f1858523049c911e2da34ce
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#115|https://github.com/apache/cassandra-website/pull/115]|[7855f25|https://github.com/apache/cassandra-website/commit/7855f251453642df2f1858523049c911e2da34ce]|
> WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
>
>
> Key: CASSANDRA-17479
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17479
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png
>
>
> This ticket is to capture the work associated with adding a new case study to
> the website and entry on the Case Studies page.
> * Add Kinetic Data case study
> * Add Kinetic Data card to Case Studies page
> * Add Kinetic Data logo to images: kinetic_data.svg
> * Fix Backblaze case study typo
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Add Kinetic Data to Case Studies, fix Backblaze
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/trunk by this push:
new 7855f25 Add Kinetic Data to Case Studies, fix Backblaze
7855f25 is described below
commit 7855f251453642df2f1858523049c911e2da34ce
Author: Diogenese Topper
AuthorDate: Thu Mar 24 11:31:41 2022 -0700
Add Kinetic Data to Case Studies, fix Backblaze
patch by Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17479
---
.../modules/ROOT/images/companies/kinetic_data.svg | 22 ++
.../source/modules/ROOT/pages/case-studies.adoc| 25 ++-
.../ROOT/pages/case-studies/Kinetic-Data.adoc | 51 ++
.../modules/ROOT/pages/case-studies/backblaze.adoc | 2 +-
4 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/site-content/source/modules/ROOT/images/companies/kinetic_data.svg
b/site-content/source/modules/ROOT/images/companies/kinetic_data.svg
new file mode 100644
index 000..aa32468
--- /dev/null
+++ b/site-content/source/modules/ROOT/images/companies/kinetic_data.svg
@@ -0,0 +1,22 @@
+
+
+http://www.w3.org/2000/svg;
xmlns:xlink="http://www.w3.org/1999/xlink; x="0px" y="0px"
+viewBox="0 0 396.2 66.8" style="enable-background:new 0 0 396.2 66.8;"
xml:space="preserve">
+
+ .st0{fill:#F36C24;}
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/site-content/source/modules/ROOT/pages/case-studies.adoc
b/site-content/source/modules/ROOT/pages/case-studies.adoc
index 0a8cc32..cfae2f1 100644
--- a/site-content/source/modules/ROOT/pages/case-studies.adoc
+++ b/site-content/source/modules/ROOT/pages/case-studies.adoc
@@ -138,7 +138,7 @@ We needed something that would handle really high write
throughput and keep scal
[openblock, card-btn text-center]
[.btn.btn--alt]
-xref:case-studies/backblaze.adoc[Read More,window=_blank]
+xref:case-studies/backblaze.adoc[Read More]
--
@@ -871,6 +871,29 @@
https://siliconangle.com/2020/10/09/data-firehose-next-generation-streaming-tech
[openblock,card-header]
--
+image:companies/kinetic_data.svg[Kinetic Data]
+--
+[openblock,card-content]
+--
+[discrete]
+=== Kinetic Data
+
+“Once it's set up and running it’s hands-off. Quite frankly, it's easy from an
operations perspective. So our customers, they're using Cassandra, but they
don't really realize it. But they do say, ‘it's always up. It's always fast.’
It's all these benefits that you really want the end-user to know about.”
+
+[openblock, card-btn text-center]
+
+[.btn.btn--alt]
+xref:case-studies/Kinetic-Data.adoc[Read More]
+
+--
+
+//end card
+
+//start card
+[openblock,card shadow relative]
+
+[openblock,card-header]
+--
image:companies/locstat_full.png[]
--
[openblock,card-content]
diff --git
a/site-content/source/modules/ROOT/pages/case-studies/Kinetic-Data.adoc
b/site-content/source/modules/ROOT/pages/case-studies/Kinetic-Data.adoc
new file mode 100644
index 000..bbd88c2
--- /dev/null
+++ b/site-content/source/modules/ROOT/pages/case-studies/Kinetic-Data.adoc
@@ -0,0 +1,51 @@
+= Kinetic Data
+:page-layout: case-study
+:page-role: case-study
+:description: The Apache Cassandra Community
+:keywords:
+
+image::companies/kinetic_data.svg[Kinetic Data,align="center"]
+
+== Kinetic Data chooses Apache Cassandra to deliver workflow automation
solution
+
+Enterprise workflow automation
+50 employees
+Global 2000 clients and government customers, including the USDA, US Army and
Navy, Federal Reserve, Fairfax County Public Schools, Emory Healthcare.
+
+**Benefits**
+
+* Distributed fault tolerance
+* Load balancing
+* Data durability through replicas
+* Low friction for operations teams
+
+Kinetic Data is a leading provider of enterprise workflow automation software.
Its Kinetic Platform combines custom workflow builds and pre-built solutions
with a low-code environment that enables tech-savvy ‘smarties’ to automate
workflow processes. The platform also features pro-code functionality that
allows architects to custom code for ease of digital transformation, helping
enterprises extend technology investments and lower costs for their systems at
scale.
+
+When it came to developing the Kinetic Platform, John Sundberg, president of
Kinetic Data wanted a data management system that was robust and minimized
friction when using the product: "Everything we do is focused on helping IT and
business professionals, those closest to the problems, build their own
solutions to those issues," says Sundberg, and when it came to building its
workflow platform, Kinetic decided to build atop of Apache Cassandra.
+
+Ultimately, Apache Cassandra was chosen for its robustness. Features including
automatic failover, load balancing, and replication eliminated many headaches
for Kinetic Data and its
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze
[ https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17479: -- Summary: WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze (was: WEBSITE - Add Kinetic Data to the Case Studies section, March 2022) > WEBSITE - Case Studies - Add Kinetic Data, fix Backblaze > > > Key: CASSANDRA-17479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17479 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png > > > This ticket is to capture the work associated with adding a new case study to > the website and entry on the Case Studies page. > * Add Kinetic Data case study > * Add Kinetic Data card to Case Studies page > * Add Kinetic Data logo to images: kinetic_data.svg > * Fix Backblaze case study typo -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Add Kinetic Data to the Case Studies section, March 2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17479: -- Status: Ready to Commit (was: Review In Progress) This is ready to commit: !c17479-01-blog-index.png|width=400! !c17479-02-blog-post.png|width=400! > WEBSITE - Add Kinetic Data to the Case Studies section, March 2022 > -- > > Key: CASSANDRA-17479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17479 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png > > > This ticket is to capture the work associated with adding a new case study to > the website and entry on the Case Studies page. > * Add Kinetic Data case study > * Add Kinetic Data card to Case Studies page > * Add Kinetic Data logo to images: kinetic_data.svg > * Fix Backblaze case study typo -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Add Kinetic Data to the Case Studies section, March 2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17479: -- Attachment: c17479-02-blog-post.png c17479-01-blog-index.png > WEBSITE - Add Kinetic Data to the Case Studies section, March 2022 > -- > > Key: CASSANDRA-17479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17479 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17479-01-blog-index.png, c17479-02-blog-post.png > > > This ticket is to capture the work associated with adding a new case study to > the website and entry on the Case Studies page. > * Add Kinetic Data case study > * Add Kinetic Data card to Case Studies page > * Add Kinetic Data logo to images: kinetic_data.svg > * Fix Backblaze case study typo -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[
https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515053#comment-17515053
]
Erick Ramirez commented on CASSANDRA-17497:
---
I've completed final verification in staging and [published to
production|https://github.com/apache/cassandra-website#merging-asf-staging-to-asf-site]:
{noformat}
$ git branch
* trunk
$ git fetch origin
$ git checkout asf-site
Branch 'asf-site' set up to track remote branch 'asf-site' from 'origin'.
Switched to a new branch 'asf-site'
$ git branch
* asf-site
trunk
$ git reset --hard origin/asf-staging
HEAD is now at 841cb1aa generate docs for 4e816112
$ git push -f origin asf-site
Username for 'https://github.com': erickramirezau
Password for 'https://erickramire...@github.com':
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/apache/cassandra-website.git
+ bcbf8106...841cb1aa asf-site -> asf-site (forced update){noformat}
The post is now live in production --
https://cassandra.apache.org/_/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.html.
> WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver
> workflow automation solution"
> -
>
> Key: CASSANDRA-17497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17497
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the March 2022
> blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation
> solution"
> If this blog cannot be published by the *March 31, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (bcbf810 -> 841cb1a)
This is an automated email from the ASF dual-hosted git repository.
erickramirezau pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard bcbf810 generate docs for 1cee962d
add 4e81611 BLOG - Kinetic Data chooses Apache Cassandra to deliver
workflow automation solution
add 841cb1a generate docs for 4e816112
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (bcbf810)
\
N -- N -- N refs/heads/asf-site (841cb1a)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
...w-automation-solution-unsplash-lukas-tennie.jpg | Bin 0 -> 1473698 bytes
content/_/blog.html| 24
...a-to-deliver-workflow-automation-solution.html} | 43 +
.../cassandra/configuration/cass_yaml_file.html| 24
.../cassandra/configuration/cass_yaml_file.html| 24
.../cassandra/configuration/cass_yaml_file.html| 24
content/search-index.js| 2 +-
...w-automation-solution-unsplash-lukas-tennie.jpg | Bin 0 -> 1473698 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25
...ra-to-deliver-workflow-automation-solution.adoc | 24
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
11 files changed, 165 insertions(+), 25 deletions(-)
create mode 100644
content/_/_images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg
copy content/_/blog/{Upgrade-Advisory2.html =>
Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.html}
(82%)
create mode 100644
site-content/source/modules/ROOT/images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515051#comment-17515051 ] Erick Ramirez commented on CASSANDRA-17497: --- Build is complete and the blog post is now in staging – https://cassandra.staged.apache.org/_/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.html. > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.3 > > Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[
https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515026#comment-17515026
]
Erick Ramirez commented on CASSANDRA-17497:
---
Staging build in progress:
||Branch||PR||Commit||Build||
|{{trunk}}|[#119|https://github.com/apache/cassandra-website/pull/119]|[4e81611|https://github.com/apache/cassandra-website/commit/4e8161124717a42a366b1b7f92c0b6d7cb6df10c]|[#169|https://ci-cassandra.apache.org/job/cassandra-website/169/]|
> WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver
> workflow automation solution"
> -
>
> Key: CASSANDRA-17497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17497
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the March 2022
> blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation
> solution"
> If this blog cannot be published by the *March 31, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (bcbf810 -> 841cb1a)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
omit bcbf810 generate docs for 1cee962d
add 4e81611 BLOG - Kinetic Data chooses Apache Cassandra to deliver
workflow automation solution
new 841cb1a generate docs for 4e816112
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (bcbf810)
\
N -- N -- N refs/heads/asf-staging (841cb1a)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
...w-automation-solution-unsplash-lukas-tennie.jpg | Bin 0 -> 1473698 bytes
content/_/blog.html| 24
...a-to-deliver-workflow-automation-solution.html} | 43 +
.../cassandra/configuration/cass_yaml_file.html| 24
.../cassandra/configuration/cass_yaml_file.html| 24
.../cassandra/configuration/cass_yaml_file.html| 24
content/search-index.js| 2 +-
...w-automation-solution-unsplash-lukas-tennie.jpg | Bin 0 -> 1473698 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 25
...ra-to-deliver-workflow-automation-solution.adoc | 24
site-ui/build/ui-bundle.zip| Bin 4740078 -> 4740078
bytes
11 files changed, 165 insertions(+), 25 deletions(-)
create mode 100644
content/_/_images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg
copy content/_/blog/{Upgrade-Advisory2.html =>
Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.html}
(82%)
create mode 100644
site-content/source/modules/ROOT/images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[
https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-17497:
--
Fix Version/s: 4.0.3
(was: NA)
Source Control Link:
https://github.com/apache/cassandra-website/commit/4e8161124717a42a366b1b7f92c0b6d7cb6df10c
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed:
||Branch||PR||Commit||
|{{trunk}}|[#119|https://github.com/apache/cassandra-website/pull/119]|[4e81611|https://github.com/apache/cassandra-website/commit/4e8161124717a42a366b1b7f92c0b6d7cb6df10c]|
> WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver
> workflow automation solution"
> -
>
> Key: CASSANDRA-17497
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17497
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Diogenese Topper
>Assignee: Diogenese Topper
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0.3
>
> Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png
>
>
> This ticket is to capture the work associated with publishing the March 2022
> blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation
> solution"
> If this blog cannot be published by the *March 31, 2022 publish date*, please
> contact me, suggest changes, or correct the date when possible in the pull
> request for the appropriate time that the blog will go live (on both the
> blog.adoc and the blog post's file).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: BLOG - Kinetic Data chooses Apache Cassandra to deliver workflow automation solution
This is an automated email from the ASF dual-hosted git repository. erickramirezau pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 4e81611 BLOG - Kinetic Data chooses Apache Cassandra to deliver workflow automation solution 4e81611 is described below commit 4e8161124717a42a366b1b7f92c0b6d7cb6df10c Author: Diogenese Topper AuthorDate: Tue Mar 29 12:04:29 2022 -0700 BLOG - Kinetic Data chooses Apache Cassandra to deliver workflow automation solution patch by Diogenese Topper; reviewed by Erick Ramirez for CASSANDRA-17497 --- ...w-automation-solution-unsplash-lukas-tennie.jpg | Bin 0 -> 1473698 bytes site-content/source/modules/ROOT/pages/blog.adoc | 25 + ...ra-to-deliver-workflow-automation-solution.adoc | 24 3 files changed, 49 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg b/site-content/source/modules/ROOT/images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg new file mode 100644 index 000..564e726 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index d03af4c..829857a 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -14,6 +14,31 @@ NOTES FOR CONTENT CREATORS [openblock,card-header] -- [discrete] +=== Kinetic Data chooses Apache Cassandra to deliver workflow automation solution +[discrete] + March 31, 2022 +-- +[openblock,card-content] +-- +Read our latest user case study. When it came to building a new platform, Kinetic Data chose Apache Cassandra as the database for building its workflow automation solution. + +[openblock,card-btn card-btn--blog] + + +[.btn.btn--alt] +xref:blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc[Read More] + + +-- + +//end card + +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] === Inside Cassandra: An Interview with Project Contributor, Lorina Poland [discrete] March 17, 2022 diff --git a/site-content/source/modules/ROOT/pages/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc b/site-content/source/modules/ROOT/pages/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc new file mode 100644 index 000..cbd74c6 --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Kinetic-Data-chooses-Apache-Cassandra-to-deliver-workflow-automation-solution.adoc @@ -0,0 +1,24 @@ += Kinetic Data chooses Apache Cassandra to deliver workflow automation solution +:page-layout: single-post +:page-role: blog-post +:page-post-date: March 31, 2022 +:page-post-author: The Apache Cassandra Community +:description: The Apache Cassandra Community +:keywords: + +:!figure-caption: + +.Image credit: https://unsplash.com/@luk10[Lukas Tennie^] on Unsplash +image::blog/kinetic-data-chooses-apache-cassandra-to-deliver-workflow-automation-solution-unsplash-lukas-tennie.jpg[gears] + +For the blog this week, we’re highlighting the recently published Cassandra case study from Kinetic Data, a provider of enterprise workflow automation software. + +Apache Cassandra is trusted by thousands of companies and not all of them operate on a global scale. The release of Cassandra 4.0 brought many xref:blog/Apache-Cassandra-4.0-Overview.adoc[improvements] to consistency, speed, latency and much more that has seen it adopted by a wide variety of businesses seeking rock-solid stability from a noSQL distributed database. + +The company’s Kinetic Platform is built on top of Apache Cassandra. With Global 2000 clients and government customers, Kinetic Data can and does operate at scale, for example, automating the acquisition of over $4 billion worth of equipment orders for DISA, a U.S. Department of Defense combat support agency, and helping to onboard 1,000 new students a month at a training hospital, but not every client needs that: “I always hear these super-big data stories", says John Sundberg, President [...] + +=== Apache Cassandra appeal + +Sundberg cites features including automatic failover, load balancing, and replication as key reasons for choosing Cassandra as it eliminated many headaches for the company and its customers. Sunderberg also says the fact Cassandra is open source was appealing as it reduced the friction for clients as they would not have to
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Add Kinetic Data to the Case Studies section, March 2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17479: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - Add Kinetic Data to the Case Studies section, March 2022 > -- > > Key: CASSANDRA-17479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17479 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with adding a new case study to > the website and entry on the Case Studies page. > * Add Kinetic Data case study > * Add Kinetic Data card to Case Studies page > * Add Kinetic Data logo to images: kinetic_data.svg > * Fix Backblaze case study typo -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17479) WEBSITE - Add Kinetic Data to the Case Studies section, March 2022
[ https://issues.apache.org/jira/browse/CASSANDRA-17479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17479: -- Authors: Diogenese Topper (was: Chris Thornett) > WEBSITE - Add Kinetic Data to the Case Studies section, March 2022 > -- > > Key: CASSANDRA-17479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17479 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with adding a new case study to > the website and entry on the Case Studies page. > * Add Kinetic Data case study > * Add Kinetic Data card to Case Studies page > * Add Kinetic Data logo to images: kinetic_data.svg > * Fix Backblaze case study typo -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17497: -- Status: Ready to Commit (was: Review In Progress) This is ready to commit: !c17497-01-blog-index.png|width=500! !c17497-02-blog-post.png|width=500! > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17497: -- Attachment: c17497-02-blog-post.png c17497-01-blog-index.png > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Attachments: c17497-01-blog-index.png, c17497-02-blog-post.png > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17497: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17497) WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation solution"
[ https://issues.apache.org/jira/browse/CASSANDRA-17497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17497: - Assignee: Diogenese Topper > WEBSITE - March 2022 blog "Kinetic Data chooses Apache Cassandra to deliver > workflow automation solution" > - > > Key: CASSANDRA-17497 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17497 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the March 2022 > blog "Kinetic Data chooses Apache Cassandra to deliver workflow automation > solution" > If this blog cannot be published by the *March 31, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17166) Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
[
https://issues.apache.org/jira/browse/CASSANDRA-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514990#comment-17514990
]
David Capwell commented on CASSANDRA-17166:
---
{code}
> assert any([msg in line for msg in acceptable]), \
'Found line \n\n"{line}"\n\n in
error\n\n{error}'.format(line=line, error=error)
E AssertionError: Found line
E
E "WARN 20:57:24,843 [request_timeout_in_ms,
key_cache_save_period, read_request_timeout_in_ms, counter_cache_save_period,
range_request_timeout_in_ms, truncate_request_timeout_in_ms,
write_request_timeout_in_ms, row_cache_save_period] parameters have been
deprecated and may be removed next major release; For more information, please
refer to NEWS.txt"
E
E in error
E
E WARN 20:57:24,843 [request_timeout_in_ms,
key_cache_save_period, read_request_timeout_in_ms, counter_cache_save_period,
range_request_timeout_in_ms, truncate_request_timeout_in_ms,
write_request_timeout_in_ms, row_cache_save_period] parameters have been
deprecated and may be removed next major release; For more information, please
refer to NEWS.txt
E
E assert False
E+ where False = any([False, False, False, False, False,
False])
{code}
will look into updating the tests.
> Enhance SnakeYAML properties to be reusable outside of YAML parsing, support
> camel case conversion to snake case, and add support to ignore properties
> --
>
> Key: CASSANDRA-17166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17166
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 14h 40m
> Remaining Estimate: 0h
>
> SnakeYaml is rather limited in the “object mapping” layer, which forces our
> internal code to match specific patterns (all fields public and camel case);
> we can remove this restriction by leveraging Jackson for property lookup, and
> leaving the YAML handling to SnakeYAML
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514983#comment-17514983 ] Ekaterina Dimitrova edited comment on CASSANDRA-17431 at 3/30/22, 11:26 PM: So the patch can be found [here|https://github.com/ekaterinadimitrova2/cassandra/pull/194], respective properties were added in the ccm dictionary [here|https://github.com/ekaterinadimitrova2/ccm/pull/2] in order to satisfy the backward compatibility. I tried to split into different commits different changes and a few fixes I did, I had to revert one down the way, please, ignore it. I left PR commits not squashed so that reviewers can check also individual commits, to be maybe easier and shorter. Let me know if you prefer everything squashed. * As I mentioned already, I didn't touch phi_convict_threshold and meltable_cleanup_threshold. * I pinged the author about _repair_request_timeout_in_ms,_ it seems that one is not needed so he will open a ticket to remove it actually. __ * While working on _block_for_peers_timeout_in_secs_ I realized I have a bug in MILLIS_CUSTOM_DURATION, -1 should mean null, not 0 which would change the meaning. This led me also to a few more checks to be added in the DatabaseDescriptor. While we don't advertise that negative numbers except -1 can be used, we weren't really prohibiting it so I am throwing an exception now in the setter. Please check if you think this is valid way to handle this and I am not breaking anything. I added one more unit test to cover this special case. The idea for the null usage came from [~dcapwell], also one test added in the YAMLConfigurationLoaderTest is his. * I ended up not transferring block_for_peers_timeout_in_secs as I noticed that it can handle even negative numbers which are not rejecter internally by TimeUnit so I am hesitant to touch this advanced parameter. I will probably discuss it on the mailing list which I plan to hit after this patch to confirm with people all special cases we have to validate things before the release. * While, currently it is not a problem with the current config, we shouldn't be assigning 0ms in case a property is null but keep it null. This led me to a change in the MILLIS_DOUBLE_DURATION in regards to the NaN handling for backward compatibility. While on that I removed the handling of 0 which was supposed to be accepted without unit too. I remember we were discussing that 0 with a unit might be weird so I can return it back if we think it is better to be there. This led to broken Paxos tests where 0 without a unit was used. I fixed those to have a unit but if we prefer really the old way, I will revert the change. * I am not 100% sure whether there might be some issue with the new Converter NEGATIVE_SECONDS_DURATION for validation_preview_purge_head_start_in_sec. I didn't break any tests but that is not a guarantee as we know... Any check/advice/suggestion/confirmation will be highly appreciated. * native_transport_receive_queue_capacity_in_bytes - as I left a comment also in the code (in order not to forget to mention it during review :) ), this one is not guarded and mentioned whether it can be negative, etc anywhere. I definitely have to confirm it with the author/community before doing anything. [Here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1487/workflows/ae03b64c-1300-4ed8-a324-4b1ccd176d47] is a preliminary J8 run, I will run also J11 when we are done with the review. I was running them down the road. So the only failures that are not already presented on trunk and which don't have tickets are the Paxos tests failures and the usage of 0 I mentioned. I pushed commit to fix them after the CI run. [~dcapwell], [~maedhroz] , I think this is ready for review and discussions around the corner cases, thank you! was (Author: e.dimitrova): So the patch can be found [here|https://github.com/ekaterinadimitrova2/cassandra/pull/194], respective properties were added in the ccm dictionary [here|https://github.com/ekaterinadimitrova2/ccm/compare/master-master...ekaterinadimitrova2:17431-trunk] in order to satisfy the backward compatibility. I tried to split into different commits different changes and a few fixes I did, I had to revert one down the way, please, ignore it. I left PR commits not squashed so that reviewers can check also individual commits, to be maybe easier and shorter. Let me know if you prefer everything squashed. * As I mentioned already, I didn't touch phi_convict_threshold and meltable_cleanup_threshold. * I pinged the author about _repair_request_timeout_in_ms,_ it seems that one is not needed so he will open a ticket to remove it actually. __ * While working on _block_for_peers_timeout_in_secs_ I realized I have a bug in MILLIS_CUSTOM_DURATION, -1 should mean
[jira] [Updated] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17431: Test and Documentation Plan: [trunk|https://github.com/ekaterinadimitrova2/cassandra/pull/194], [ccm|https://github.com/ekaterinadimitrova2/ccm/pull/2], the current tests were updated plus a few more new checks added. Status: Patch Available (was: In Progress) > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514983#comment-17514983 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - So the patch can be found [here|https://github.com/ekaterinadimitrova2/cassandra/pull/194], respective properties were added in the ccm dictionary [here|https://github.com/ekaterinadimitrova2/ccm/compare/master-master...ekaterinadimitrova2:17431-trunk] in order to satisfy the backward compatibility. I tried to split into different commits different changes and a few fixes I did, I had to revert one down the way, please, ignore it. I left PR commits not squashed so that reviewers can check also individual commits, to be maybe easier and shorter. Let me know if you prefer everything squashed. * As I mentioned already, I didn't touch phi_convict_threshold and meltable_cleanup_threshold. * I pinged the author about _repair_request_timeout_in_ms,_ it seems that one is not needed so he will open a ticket to remove it actually. __ * While working on _block_for_peers_timeout_in_secs_ I realized I have a bug in MILLIS_CUSTOM_DURATION, -1 should mean null, not 0 which would change the meaning. This led me also to a few more checks to be added in the DatabaseDescriptor. While we don't advertise that negative numbers except -1 can be used, we weren't really prohibiting it so I am throwing an exception now in the setter. Please check if you think this is valid way to handle this and I am not breaking anything. I added one more unit test to cover this special case. The idea for the null usage came from [~dcapwell], also one test added in the YAMLConfigurationLoaderTest is his. * I ended up not transferring block_for_peers_timeout_in_secs as I noticed that it can handle even negative numbers which are not rejecter internally by TimeUnit so I am hesitant to touch this advanced parameter. I will probably discuss it on the mailing list which I plan to hit after this patch to confirm with people all special cases we have to validate things before the release. * While, currently it is not a problem with the current config, we shouldn't be assigning 0ms in case a property is null but keep it null. This led me to a change in the MILLIS_DOUBLE_DURATION in regards to the NaN handling for backward compatibility. While on that I removed the handling of 0 which was supposed to be accepted without unit too. I remember we were discussing that 0 with a unit might be weird so I can return it back if we think it is better to be there. This led to broken Paxos tests where 0 without a unit was used. I fixed those to have a unit but if we prefer really the old way, I will revert the change. * I am not 100% sure whether there might be some issue with the new Converter NEGATIVE_SECONDS_DURATION for validation_preview_purge_head_start_in_sec. I didn't break any tests but that is not a guarantee as we know... Any check/advice/suggestion/confirmation will be highly appreciated. * native_transport_receive_queue_capacity_in_bytes - as I left a comment also in the code (in order not to forget to mention it during review :) ), this one is not guarded and mentioned whether it can be negative, etc anywhere. I definitely have to confirm it with the author/community before doing anything. [Here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1487/workflows/ae03b64c-1300-4ed8-a324-4b1ccd176d47] is a preliminary J8 run, I will run also J11 when we are done with the review. I was running them down the road. So the only failures that are not already presented on trunk and which don't have tickets are the Paxos tests failures and the usage of 0 I mentioned. I pushed commit to fix them after the CI run. [~dcapwell], [~maedhroz] , I think this is ready for review and discussions around the corner cases, thank you! > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17431: Reviewers: Caleb Rackliffe, David Capwell (was: Caleb Rackliffe) > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-16456: -- Status: Review In Progress (was: Patch Available) > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17166) Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
[
https://issues.apache.org/jira/browse/CASSANDRA-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514952#comment-17514952
]
Caleb Rackliffe commented on CASSANDRA-17166:
-
The patch LGTM.
There are a [few dtests that
fail|https://app.circleci.com/pipelines/github/dcapwell/cassandra/1295/workflows/0e5aba57-c9a6-4b23-81a2-a6472f7669ab/jobs/10417/tests#failed-test-4]
because of the minor change to the warning message in {{PropertiesChecker}},
but it should be pretty easy to fix that on the dtest side.
> Enhance SnakeYAML properties to be reusable outside of YAML parsing, support
> camel case conversion to snake case, and add support to ignore properties
> --
>
> Key: CASSANDRA-17166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17166
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 12h 20m
> Remaining Estimate: 0h
>
> SnakeYaml is rather limited in the “object mapping” layer, which forces our
> internal code to match specific patterns (all fields public and camel case);
> we can remove this restriction by leveraging Jackson for property lookup, and
> leaving the YAML handling to SnakeYAML
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Houser updated CASSANDRA-16456: - Mentor: Stefan Miklosovic Test and Documentation Plan: Verified via Sigv4 auth plugin, PlainTextAuth standard. Tested from ini file, old command line, and new command lines. Will submit separate patch for adding to docs in website Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/1538 > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17166) Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
[ https://issues.apache.org/jira/browse/CASSANDRA-17166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17166: -- Reviewers: Caleb Rackliffe, Stefan Miklosovic (was: Caleb Rackliffe) > Enhance SnakeYAML properties to be reusable outside of YAML parsing, support > camel case conversion to snake case, and add support to ignore properties > -- > > Key: CASSANDRA-17166 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17166 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.x > > Time Spent: 11h > Remaining Estimate: 0h > > SnakeYaml is rather limited in the “object mapping” layer, which forces our > internal code to match specific patterns (all fields public and camel case); > we can remove this restriction by leveraging Jackson for property lookup, and > leaving the YAML handling to SnakeYAML -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514904#comment-17514904
]
Brandon Williams commented on CASSANDRA-17411:
--
Sure, I think that makes sense. What I can confirm here is that the
_coordinator_ isn't sending requests to the dead node, so there's nothing we
can do on the server side for this behavior.
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,095 - target-dc3 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,148 - target-dc2 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:42,589 - target-dc1 - __main__ - INFO - Got 7/13 (53.846154)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,125 - target-dc3 - __main__ - INFO - Got 0/567 (0.00)
[jira] [Updated] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17411:
-
Resolution: Not A Problem
Status: Resolved (was: Open)
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,095 - target-dc3 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,148 - target-dc2 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:42,589 - target-dc1 - __main__ - INFO - Got 7/13 (53.846154)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,125 - target-dc3 - __main__ - INFO - Got 0/567 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:51:39,159 - target-dc2 - __main__ - INFO - Got 0/567 (0.00)
> timeouts/total_rqs in the last 1 minute
>
[jira] [Commented] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514902#comment-17514902
]
Pere Balaguer commented on CASSANDRA-17411:
---
Ah now I get where your brain was going towards, I thought you had problems
reproducing the issue.
Fair enough, it is a bit "odd" the exact behavior happens in at least 2
different drivers (java & python) which is why I opened it here but anyway,
I'll open tickets in their queues and reference this one for completeness if
that seems ok to you.
> Network partition causes write ONE timeouts when using counters in Cassandra 4
> --
>
> Key: CASSANDRA-17411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17411
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Pere Balaguer
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: app.py
>
>
> h5. Affected versions:
> * 4.x
> h5. Observed behavior:
> When executing CL=ONE writes on a table with a counter column, if one of the
> nodes is network partitioned from the others, clients keep sending requests
> to it.
> Even though this may be a "driver" problem, I've been able to reproduce it
> with both java and python datastax drivers using their latest available
> versions and given the behavior only changes depending on the Cassandra
> version, well, here I am.
> h5. Expected behavior:
> In Cassandra 3 after all inflight requests fail (expected), no new requests
> are sent to the partitioned node. The expectation is that Cassandra 4 behaves
> the same way.
> h5. How to reproduce:
> {noformat}
> # Create a cluster with the desired version, will go with 4.x for this example
> ccm create bug-report -v 4.0.3
> ccm populate -n 2:2:2
> ccm start
> # Create schemas and so on
> CQL=$(cat < CONSISTENCY ALL;
> DROP KEYSPACE IF EXISTS demo;
> CREATE KEYSPACE demo WITH REPLICATION = {'class': 'NetworkTopologyStrategy',
> 'dc1': 2, 'dc2': 2, 'dc3': 2};
> CREATE TABLE demo.demo (pk uuid PRIMARY KEY, count counter) WITH compaction =
> {'class': 'LeveledCompactionStrategy'};
> END
> )
> ccm node1 cqlsh --verbose --exec="${CQL}"
> # Launch the attached app.py
> # requires cassandra-driver
> python3 app.py "127.0.0.1" "9042"
> # Wait a bit for the app to settle, proceed to next step once you see 3
> messages in stdout like:
> # 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572
> (0.00) timeouts/total_rqs in the last 1 minute
> # Partition one node with iptables
> iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port 7000 -j
> DROP; iptables -A INPUT -p tcp --destination 127.0.0.1 --destination-port
> 9042 -j DROP
> {noformat}
> Some time after executing the iptables command in cassandra-3 the output
> should be similar to:
> {noformat}
> 2022-03-01 15:41:51,557 - target-dc2 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:51,576 - target-dc3 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:41:58,032 - target-dc1 - __main__ - INFO - Got 6/252 (2.380952)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,560 - target-dc2 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:51,620 - target-dc3 - __main__ - INFO - Got 0/570 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:42:58,101 - target-dc1 - __main__ - INFO - Got 2/354 (0.564972)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,602 - target-dc2 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:51,672 - target-dc3 - __main__ - INFO - Got 0/571 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:43:58,153 - target-dc1 - __main__ - INFO - Got 0/572 (0.00)
> timeouts/total_rqs in the last 1 minute
> {noformat}
> as the timeouts/rqs shows, in about 2 minutes the partitioned node stops
> receiving traffic
> while as in cassandra-4
> {noformat}
> 2022-03-01 15:49:39,068 - target-dc3 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:39,107 - target-dc2 - __main__ - INFO - Got 0/566 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:49:41,206 - target-dc1 - __main__ - INFO - Got 2/444 (0.450450)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,095 - target-dc3 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:39,148 - target-dc2 - __main__ - INFO - Got 0/569 (0.00)
> timeouts/total_rqs in the last 1 minute
> 2022-03-01 15:50:42,589 - target-dc1 - __main__ -
[jira] [Assigned] (CASSANDRA-17470) Default directory permissions for /var/lib/cassandra could be more restrictive
[
https://issues.apache.org/jira/browse/CASSANDRA-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-17470:
Assignee: Brandon Williams
> Default directory permissions for /var/lib/cassandra could be more restrictive
> --
>
> Key: CASSANDRA-17470
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17470
> Project: Cassandra
> Issue Type: Improvement
> Components: Packaging
>Reporter: Sebastian Schulze
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> I noticed that the default permissions for /var/lib/cassandra and everything
> below seem to be "world readable", e.g. "{{{}drwxr-xr-x 6 cassandra
> cassandra{}}}".
> It might depend on the distribution / package used, but I can at least
> confirm this for the official Cassandra Debian packages as well as the Docker
> containers. Out of curiosity I compared it to Postgres and MySQL to see which
> defaults they would opt for and they are
> {{drwxr-x--- 2 mysql mysql 4.0K Mar 22 10:00 mysql}}
> and respectively
> {{drwx-- 19 postgres postgres 4.0K Mar 22 10:01 data}}
> which is way more appropriate in my option. ([Here is a Gist with the script
> to compare
> them|https://gist.github.com/bascht/31fa749d4121b9898902d5d557a01f82])
> If there is no particular reason behind this, I would suggest that the
> default packages should have stricter ulimits that restricts access to the
> data directory to the cassandra user & group.
> (See also this [mailing list
> thread|https://lists.apache.org/thread/gyoqb4xnq4ry0c726f0ntz83rvn0w5kx])
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17411) Network partition causes write ONE timeouts when using counters in Cassandra 4
[
https://issues.apache.org/jira/browse/CASSANDRA-17411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514899#comment-17514899
]
Brandon Williams commented on CASSANDRA-17411:
--
Here it is with more time:
{noformat}
2022-03-30 18:57:07,763 - target-dc1 - cassandra.connection - WARNING -
Heartbeat failed for connection (139719619682112) to 127.0.0.1:9042
2022-03-30 18:57:07,776 - target-dc3 - cassandra.connection - WARNING -
Heartbeat failed for connection (139719619681680) to 127.0.0.1:9042
2022-03-30 18:57:07,980 - target-dc2 - __main__ - INFO - Got 0/579 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:57:08,094 - target-dc3 - __main__ - INFO - Got 0/579 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:57:12,768 - target-dc1 - cassandra.cluster - WARNING - [control
connection] Error connecting to 127.0.0.1:9042:
Traceback (most recent call last):
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/cluster.py",
line 3522, in _reconnect_internal
return self._try_connect(host)
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/cluster.py",
line 3544, in _try_connect
connection = self._cluster.connection_factory(host.endpoint,
is_control_connection=True)
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/cluster.py",
line 1620, in connection_factory
return self.connection_class.factory(endpoint, self.connect_timeout, *args,
**kwargs)
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/connection.py",
line 831, in factory
conn = cls(endpoint, *args, **kwargs)
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/io/asyncorereactor.py",
line 344, in __init__
self._connect_socket()
File
"/home/drift/cassandra-dtest/venv/src/cassandra-driver/cassandra/connection.py",
line 898, in _connect_socket
raise socket.error(sockerr.errno, "Tried connecting to %s. Last error: %s" %
OSError: [Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error:
timed out
2022-03-30 18:57:12,831 - target-dc1 - __main__ - INFO - Got 5/190 (2.631579)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:57:37,774 - target-dc1 - cassandra.connection - WARNING -
Heartbeat failed for connection (139719602362976) to 127.0.0.1:9042
2022-03-30 18:57:37,775 - target-dc1 - cassandra.cluster - WARNING - Host
127.0.0.1:9042 has been marked down
2022-03-30 18:57:43,983 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 1.74 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:57:50,790 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 4.52 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:58:00,403 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 7.04 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:58:08,006 - target-dc2 - __main__ - INFO - Got 0/582 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:58:08,144 - target-dc3 - __main__ - INFO - Got 0/582 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:58:12,519 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 16.0 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:58:14,102 - target-dc1 - __main__ - INFO - Got 9/15 (60.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:58:33,550 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 33.28 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:59:08,102 - target-dc2 - __main__ - INFO - Got 0/584 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:59:08,221 - target-dc3 - __main__ - INFO - Got 0/584 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 18:59:11,914 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 55.04 seconds:
[Errno None] Tried connecting to [('127.0.0.1', 9042)]. Last error: timed out
2022-03-30 18:59:16,479 - target-dc1 - __main__ - INFO - Got 12/23 (52.173913)
timeouts/total_rqs in the last 1 minute
2022-03-30 19:00:08,126 - target-dc2 - __main__ - INFO - Got 0/586 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 19:00:08,246 - target-dc3 - __main__ - INFO - Got 0/586 (0.00)
timeouts/total_rqs in the last 1 minute
2022-03-30 19:00:12,003 - target-dc1 - cassandra.pool - WARNING - Error
attempting to reconnect to 127.0.0.1:9042, scheduling retry in 125.44 seconds:
[jira] [Commented] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514889#comment-17514889 ] Brandon Williams commented on CASSANDRA-17504: -- Maybe try from the other direction, "uncompressedAllowed" or something? > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17496: - Reviewers: Brandon Williams (was: Brandon Williams, Josh McKenzie) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17496: -- Fix Version/s: 4.1 Since Version: 4.1 Source Control Link: https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=commit;h=1a4dccd3b9f9bfefbccbbe383982306d3aeea1d1 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17496: -- Reviewers: Brandon Williams, Josh McKenzie Status: Review In Progress (was: Patch Available) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17496: -- Status: Ready to Commit (was: Review In Progress) > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Fix AlterTest.testCreateAlterNetworkTopologyWithDefaults
This is an automated email from the ASF dual-hosted git repository.
jmckenzie pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 1a4dccd Fix AlterTest.testCreateAlterNetworkTopologyWithDefaults
1a4dccd is described below
commit 1a4dccd3b9f9bfefbccbbe383982306d3aeea1d1
Author: Josh McKenzie
AuthorDate: Tue Mar 29 12:30:05 2022 -0400
Fix AlterTest.testCreateAlterNetworkTopologyWithDefaults
Patch by Josh McKenzie; reviewed by Brandon Williams for CASSANDRA-17496
---
.../unit/org/apache/cassandra/cql3/validation/operations/AlterTest.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/test/unit/org/apache/cassandra/cql3/validation/operations/AlterTest.java
b/test/unit/org/apache/cassandra/cql3/validation/operations/AlterTest.java
index 2b8fc0a..acabdea 100644
--- a/test/unit/org/apache/cassandra/cql3/validation/operations/AlterTest.java
+++ b/test/unit/org/apache/cassandra/cql3/validation/operations/AlterTest.java
@@ -279,7 +279,7 @@ public class AlterTest extends CQLTester
assertRowsIgnoringOrderAndExtra(execute("SELECT keyspace_name,
durable_writes, replication FROM system_schema.keyspaces"),
row(KEYSPACE, true, map("class",
"org.apache.cassandra.locator.SimpleStrategy", "replication_factor", "1")),
row(KEYSPACE_PER_TEST, true,
map("class", "org.apache.cassandra.locator.SimpleStrategy",
"replication_factor", "1")),
-row(ks1, true, map("class",
"org.apache.cassandra.locator.NetworkTopologyStrategy", DATA_CENTER, "0",
DATA_CENTER_REMOTE, "3")));
+row(ks1, true, map("class",
"org.apache.cassandra.locator.NetworkTopologyStrategy", DATA_CENTER_REMOTE,
"3")));
schemaChange("ALTER KEYSPACE " + ks1 + " WITH replication = { 'class'
: 'NetworkTopologyStrategy', '" + DATA_CENTER_REMOTE + "': 3 }");
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514885#comment-17514885 ] Josh McKenzie commented on CASSANDRA-17504: --- Struggled with the naming on this one. Settled on "canUsersDisableCompression" internally since "compressionDisableEnabled" is clearly bad. > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17504: -- Test and Documentation Plan: New unit testing of the guardrail Status: Patch Available (was: Open) > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17504: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514876#comment-17514876 ] Josh McKenzie commented on CASSANDRA-17504: --- [PR|https://github.com/apache/cassandra/pull/1537] [JDK8 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/198/workflows/21e375c1-4044-47b6-a855-40a4490bf8fc] [JDK11 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/198/workflows/8e639010-0c7f-4141-bd81-59809eb04c31] > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
[ https://issues.apache.org/jira/browse/CASSANDRA-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-17504: - Assignee: Josh McKenzie > Add Guardrail to disallow creation of uncompressed tables > - > > Key: CASSANDRA-17504 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > In some cases it can be useful to remove users' ability to create tables > _without_ compression while still leaving them with all other schema mutation > capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17504) Add Guardrail to disallow creation of uncompressed tables
Josh McKenzie created CASSANDRA-17504: - Summary: Add Guardrail to disallow creation of uncompressed tables Key: CASSANDRA-17504 URL: https://issues.apache.org/jira/browse/CASSANDRA-17504 Project: Cassandra Issue Type: New Feature Components: Feature/Guardrails Reporter: Josh McKenzie In some cases it can be useful to remove users' ability to create tables _without_ compression while still leaving them with all other schema mutation capabilities. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17502) Security enforcement by enabling "two-man rule" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Repasi updated CASSANDRA-17502:
-
Description:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two different admin_guys of the available ones
above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
was:
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two of the three admin_guys above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
> Security enforcement by enabling "two-man rule" authorization
> -
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the
[jira] [Updated] (CASSANDRA-16108) Concurrent Index Memtable implementation using Trie
[
https://issues.apache.org/jira/browse/CASSANDRA-16108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16108:
Authors: (was: ratcharod)
> Concurrent Index Memtable implementation using Trie
> ---
>
> Key: CASSANDRA-16108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16108
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Zhao Yang
>Assignee: ratcharod
>Priority: Normal
> Fix For: 4.x
>
>
> Replace existing \{{ConcurrentRadixTree}} with Trie implementation for both
> numeric index and string index to reduce memory usage.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ayers updated CASSANDRA-17503: --- Priority: High (was: Normal) > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature >Reporter: Paul Ayers >Priority: High > Fix For: 4.x > > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ayers updated CASSANDRA-17503: --- Component/s: (was: Consistency/Streaming) > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature >Reporter: Paul Ayers >Priority: Normal > Fix For: 4.x > > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17502) Security enforcement by enabling "two-man rule" authorization
[
https://issues.apache.org/jira/browse/CASSANDRA-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514835#comment-17514835
]
C. Scott Andreas commented on CASSANDRA-17502:
--
Tibor, thank you for bringing discussion on this feature to the mailing list
and proposing the feature in JIRA!
Project contributors have recently made an effort to update some areas of the
Apache Cassandra codebase to adopt inclusive language. Can I propose we discuss
this feature in terms of a "two-person rule" for authorization and
"administrator_1" rather than "admin_guy1" or similar?
Thanks!
> Security enforcement by enabling "two-man rule" authorization
> -
>
> Key: CASSANDRA-17502
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Tibor Repasi
>Priority: Normal
>
> Inspired by the
> [discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
> about improving security administration the idea came up to enforce "two-man
> rule" grant of roles.
> Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
> {quote}The two-man rule is a control mechanism designed to achieve a high
> level of security for especially critical material or operations. Under this
> rule access and actions require the presence of two or more authorized people
> at all times.
> {quote}
> The idea summarise as having an option - e.g. GRANTORS - on roles to define
> how many grantors does it need for a user to have a specific role granted.
> Think about a keyspace containing highly sensitive data (e.g. patientdata)
> and a role - patientdata_access - allowing its grantees to access the data.
> {code}
> CREATE KEYSPACE patientdata …;
> CREATE ROLE patientdata_access WITH GRANTORS=2;
> GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
> CREATE ROLE security_admin;
> GRANT AUTHORIZE patientdata_access TO security_admin;
> GRANT security_admin TO admin_guy1;
> GRANT security_admin TO admin_guy2;
> GRANT security_admin TO admin_guy3;
> {code}
> Security admins are allowed to grant the role, but it would need at least two
> of them (as defined by GRANTORS) to do so to allow the user to actually
> access the data.
> Thus,
> {code}
> GRANT patientdata_access TO doctor_house;
> {code}
> must be conducted by at least two of the three admin_guys above.
> When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17503: - Change Category: Operability Complexity: Normal Component/s: Consistency/Streaming Fix Version/s: 4.1 Priority: Normal (was: High) Status: Open (was: Triage Needed) > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Streaming >Reporter: Paul Ayers >Priority: Normal > Fix For: 4.1 > > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17503: - Fix Version/s: 4.x (was: 4.1) > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature > Components: Consistency/Streaming >Reporter: Paul Ayers >Priority: Normal > Fix For: 4.x > > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ayers updated CASSANDRA-17503: --- Priority: High (was: Normal) > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature >Reporter: Paul Ayers >Priority: High > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-17503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ayers updated CASSANDRA-17503: --- Description: Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' was ran without any options in a new DC and the system.available_ranges_v2 table was populated such that every subsequent run of 'nodetool rebuild ' streamed no data. The problem was that the first run looked at only the new DC so no data was streamed, then the next run that provided the correct source DC still resulted in no streamed data. Once the system.available_ranges_v2 table was truncated, rebuild worked as expected. The request here is to include the same code that allows the following options to be used in DSE so one could easily resolve this by using '-m reset' in a similar scenario: -m, --mode mode * normal - conventional behavior, streams only ranges that are not already locally available * refetch - resets locally available ranges, streams all ranges but leaves current data untouched * reset - resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges * reset-no-snapshot - (like reset) resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges but prevents a snapshot even if auto_snapshot is enabled Protecting against updating the available_ranges table if a local DC was chosen might also be a good idea. was: Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' was ran without any options in a new DC and the system.available_ranges_v2 table was populated such that every subsequent run of 'nodetool rebuild ' streamed no data. The problem was that the first run looked at only the new DC so no data was streamed, then the next run that provided the correct source DC still resulted in no streamed data. Once the system.available_ranges_v2 table was truncated, rebuild worked as expected. The request here is to include the same code that allows the following options to be used in DSE so one could easily resolve this by using '-m reset' in a similar scenario: -m, --mode mode * normal - conventional behavior, streams only ranges that are not already locally available * refetch - resets locally available ranges, streams all ranges but leaves current data untouched * reset - resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges * reset-no-snapshot - (like reset) resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges but prevents a snapshot even if auto_snapshot is enabled > Request to port the DSE rebuild options to Cassandra > > > Key: CASSANDRA-17503 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 > Project: Cassandra > Issue Type: New Feature >Reporter: Paul Ayers >Priority: Normal > > Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' > was ran without any options in a new DC and the system.available_ranges_v2 > table was populated such that every subsequent run of 'nodetool rebuild > ' streamed no data. > The problem was that the first run looked at only the new DC so no data was > streamed, then the next run that provided the correct source DC still > resulted in no streamed data. > Once the system.available_ranges_v2 table was truncated, rebuild worked as > expected. > The request here is to include the same code that allows the following > options to be used in DSE so one could easily resolve this by using '-m > reset' in a similar scenario: > -m, --mode mode > * normal - conventional behavior, streams only ranges that are not already > locally available > * refetch - resets locally available ranges, streams all ranges but leaves > current data untouched > * reset - resets the locally available ranges, removes all locally present > data (like a TRUNCATE), streams all ranges > * reset-no-snapshot - (like reset) resets the locally available ranges, > removes all locally present data (like a TRUNCATE), streams all ranges but > prevents a snapshot even if auto_snapshot is enabled > Protecting against updating the available_ranges table if a local DC was > chosen might also be a good idea. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17503) Request to port the DSE rebuild options to Cassandra
Paul Ayers created CASSANDRA-17503: -- Summary: Request to port the DSE rebuild options to Cassandra Key: CASSANDRA-17503 URL: https://issues.apache.org/jira/browse/CASSANDRA-17503 Project: Cassandra Issue Type: New Feature Reporter: Paul Ayers Testing rebuild in C* 4.0.1, I ran into a scenario where 'nodetool rebuild' was ran without any options in a new DC and the system.available_ranges_v2 table was populated such that every subsequent run of 'nodetool rebuild ' streamed no data. The problem was that the first run looked at only the new DC so no data was streamed, then the next run that provided the correct source DC still resulted in no streamed data. Once the system.available_ranges_v2 table was truncated, rebuild worked as expected. The request here is to include the same code that allows the following options to be used in DSE so one could easily resolve this by using '-m reset' in a similar scenario: -m, --mode mode * normal - conventional behavior, streams only ranges that are not already locally available * refetch - resets locally available ranges, streams all ranges but leaves current data untouched * reset - resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges * reset-no-snapshot - (like reset) resets the locally available ranges, removes all locally present data (like a TRUNCATE), streams all ranges but prevents a snapshot even if auto_snapshot is enabled -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17417: - Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/768bdffe5298b937bfafc2eb42fb93454cfca521 Resolution: Fixed Status: Resolved (was: Ready to Commit) Committed, thanks! > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17417: - Status: Ready to Commit (was: Review In Progress) > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17417: - Status: Review In Progress (was: Needs Committer) > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17502) Security enforcement by enabling "two-man rule" authorization
Tibor Repasi created CASSANDRA-17502:
Summary: Security enforcement by enabling "two-man rule"
authorization
Key: CASSANDRA-17502
URL: https://issues.apache.org/jira/browse/CASSANDRA-17502
Project: Cassandra
Issue Type: New Feature
Reporter: Tibor Repasi
Inspired by the
[discussion|https://lists.apache.org/thread/4p92o2obvztkl12hvnrrmlw0cgtl391k]
about improving security administration the idea came up to enforce "two-man
rule" grant of roles.
Explanation from [Wikipedia|https://en.wikipedia.org/wiki/Two-man_rule]:
{quote}The two-man rule is a control mechanism designed to achieve a high level
of security for especially critical material or operations. Under this rule
access and actions require the presence of two or more authorized people at all
times.
{quote}
The idea summarise as having an option - e.g. GRANTORS - on roles to define how
many grantors does it need for a user to have a specific role granted.
Think about a keyspace containing highly sensitive data (e.g. patientdata) and
a role - patientdata_access - allowing its grantees to access the data.
{code}
CREATE KEYSPACE patientdata …;
CREATE ROLE patientdata_access WITH GRANTORS=2;
GRANT SELECT, MODIFY ON patientdata TO patientdata_access;
CREATE ROLE security_admin;
GRANT AUTHORIZE patientdata_access TO security_admin;
GRANT security_admin TO admin_guy1;
GRANT security_admin TO admin_guy2;
GRANT security_admin TO admin_guy3;
{code}
Security admins are allowed to grant the role, but it would need at least two
of them (as defined by GRANTORS) to do so to allow the user to actually access
the data.
Thus,
{code}
GRANT patientdata_access TO doctor_house;
{code}
must be conducted by at least two of the three admin_guys above.
When GRANTORS defaults to 1, the default behaviour of roles doesn't change.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17417: - Status: Needs Committer (was: Patch Available) > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: change six functions in cqlshlib to native Python 3 ones
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
The following commit(s) were added to refs/heads/trunk by this push:
new 768bdff change six functions in cqlshlib to native Python 3 ones
768bdff is described below
commit 768bdffe5298b937bfafc2eb42fb93454cfca521
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Thu Mar 10 21:18:30 2022 -0500
change six functions in cqlshlib to native Python 3 ones
patch by Brad Schoening; reviewed by Stefan Miklosovic and Brandon Williams
for CASSANDRA-17417
---
CHANGES.txt| 1 +
bin/cqlsh.py | 45 +++--
pylib/cqlshlib/copyutil.py | 69 --
pylib/cqlshlib/displaying.py | 2 +-
pylib/cqlshlib/formatting.py | 17 --
pylib/cqlshlib/helptopics.py | 2 +-
pylib/cqlshlib/test/ansi_colors.py | 3 +-
pylib/cqlshlib/test/run_cqlsh.py | 2 +-
pylib/cqlshlib/test/winpty.py | 4 +--
pylib/cqlshlib/tracing.py | 4 +--
pylib/cqlshlib/util.py | 2 +-
pylib/requirements.txt | 4 ---
12 files changed, 64 insertions(+), 91 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index cd1270d..cc50299 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * change six functions in cqlshlib to native Python 3 (CASSANDRA-17417)
* reduce hot-path object allocations required to record local/remote requests
against the client request metrics (CASSANDRA-17424)
* Disallow removing DC from system_auth while nodes are active in the DC
(CASSANDRA-17478)
* Add guardrail for the number of fields per UDT (CASSANDRA-17385)
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 9e0e063..481bb0b 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -110,19 +110,16 @@ if cql_zip:
ver = os.path.splitext(os.path.basename(cql_zip))[0][len(CQL_LIB_PREFIX):]
sys.path.insert(0, os.path.join(cql_zip, 'cassandra-driver-' + ver))
-third_parties = ('futures-', 'six-')
+# the driver needs dependencies
+third_parties = ('six-')
for lib in third_parties:
lib_zip = find_zip(lib)
if lib_zip:
sys.path.insert(0, lib_zip)
-# We cannot import six until we add its location to sys.path so the Python
-# interpreter can find it. Do not move this to the top.
-import six
-
-from six.moves import configparser, input
-from six import StringIO, ensure_text, ensure_str
+import configparser
+from io import StringIO
warnings.filterwarnings("ignore", r".*blist.*")
try:
@@ -361,7 +358,7 @@ class DecodeError(Exception):
def maybe_ensure_text(val):
-return ensure_text(val) if val else val
+return str(val) if val else val
class FormatError(DecodeError):
@@ -426,7 +423,7 @@ def insert_driver_hooks():
class Shell(cmd.Cmd):
-custom_prompt = ensure_text(os.getenv('CQLSH_PROMPT', ''))
+custom_prompt = os.getenv('CQLSH_PROMPT', '')
if custom_prompt != '':
custom_prompt += "\n"
default_prompt = custom_prompt + "cqlsh> "
@@ -860,15 +857,14 @@ class Shell(cmd.Cmd):
def get_input_line(self, prompt=''):
if self.tty:
-self.lastcmd = input(ensure_str(prompt))
-line = ensure_text(self.lastcmd) + '\n'
+self.lastcmd = input(str(prompt))
+line = self.lastcmd + '\n'
else:
-self.lastcmd = ensure_text(self.stdin.readline())
+self.lastcmd = self.stdin.readline()
line = self.lastcmd
if not len(line):
raise EOFError
self.lineno += 1
-line = ensure_text(line)
return line
def use_stdin_reader(self, until='', prompt=''):
@@ -929,7 +925,6 @@ class Shell(cmd.Cmd):
Returns true if the statement is complete and was handled (meaning it
can be reset).
"""
-statementtext = ensure_text(statementtext)
statementtext = self.strip_comment_blocks(statementtext)
try:
statements, endtoken_escaped =
cqlruleset.cql_split_statements(statementtext)
@@ -975,7 +970,7 @@ class Shell(cmd.Cmd):
if readline is not None:
nl_count = srcstr.count("\n")
-new_hist = ensure_str(srcstr.replace("\n", " ").rstrip())
+new_hist = srcstr.replace("\n", " ").rstrip()
if nl_count > 1 and self.last_hist != new_hist:
readline.add_history(new_hist)
@@ -1026,7 +1021,6 @@ class Shell(cmd.Cmd):
self.tracing_enabled = tracing_was_enabled
def perform_statement(self, statement):
-statement = ensure_text(statement)
stmt = SimpleStatement(statement,
consistency_level=self.consistency_level,
serial_consistency_level=self.serial_consistency_level,
fetch_size=self.page_size if self.use_paging else None)
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514824#comment-17514824 ] Ekaterina Dimitrova commented on CASSANDRA-17417: - cqlsh starts fine now > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514822#comment-17514822 ] Ekaterina Dimitrova commented on CASSANDRA-17417: - Oh, sorry, I thought you plan something more for some reason. Testing now... > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514034#comment-17514034 ] Brandon Williams edited comment on CASSANDRA-17417 at 3/30/22, 4:58 PM: Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/777dcb66-7807-4f8f-bf79-6c359c8e0deb] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/eb971fbd-fd9c-47f6-b402-3169aad5d798]| was (Author: brandon.williams): Alright, round 2. This is Brad's patch and then the zip loading returned on top of that. ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/777dcb66-7807-4f8f-bf79-6c359c8e0deb] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/eb971fbd-fd9c-47f6-b402-3169aad5d798]| > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514818#comment-17514818 ] Brandon Williams edited comment on CASSANDRA-17417 at 3/30/22, 4:58 PM: [~e.dimitrova] it's in the branch above, but here you go again: ||Branch||CI| |[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-17417]|[j8|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/777dcb66-7807-4f8f-bf79-6c359c8e0deb] , [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/416/workflows/eb971fbd-fd9c-47f6-b402-3169aad5d798]| was (Author: brandon.williams): [~e.dimitrova] it's in the branch above. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514818#comment-17514818 ] Brandon Williams commented on CASSANDRA-17417: -- [~e.dimitrova] it's in the branch above. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17417) Replace use of 'six' compatibility library with python 3 equivalents
[ https://issues.apache.org/jira/browse/CASSANDRA-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514817#comment-17514817 ] Ekaterina Dimitrova commented on CASSANDRA-17417: - Let me know when the patch is ready, I can check it again on Mac. > Replace use of 'six' compatibility library with python 3 equivalents > > > Key: CASSANDRA-17417 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17417 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Attachments: signature.asc, signature.asc, six.pdf > > Time Spent: 5h 50m > Remaining Estimate: 0h > > _Six_ is a _Python_ 2 and 3 compatibility library. It provides simple > utilities for wrapping the differences between Python 2 and Python 3. It is > intended to support codebases that work on both Python 2 and 3. > Since CQLSH requires python version >= 3.6, its use can be replaced with > native python 3 constructs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514798#comment-17514798 ] Josh McKenzie commented on CASSANDRA-17495: --- Having a single knob to remove dangerous functionality from your userbase is superior to having a N step process where N is your number of users in my opinion. This is similar to the ticket about secondary indexes, where we *can* do it with the existing mechanisms, but it's more onerous for operators, more brittle, more prone to error, and more prone to "leakage" (in this case, someone creating a new user, forgetting to add the role w/the revoked permissions to that user, and then that user circumventing the intended feature blockage). > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514706#comment-17514706
]
Benjamin Lerer edited comment on CASSANDRA-17458 at 3/30/22, 4:19 PM:
--
I had a look at the code and the patch will fix this specific use case but it
looks like CEP-14 might have introduced similar problems for other methods
from QueryProcessor.
The following seems suspicious to me:
* executeInternalWithNow
* executeInternalRawWithNow
was (Author: blerer):
I had a look at the code and the patch will fix this specific use case but it
looks like CEP-14 introduced similar problems for multiple methods from
QueryProcessor.
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Labels: patch-available
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17498: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17498: -- Test and Documentation Plan: New unit testing Status: Patch Available (was: Open) > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514795#comment-17514795 ] Josh McKenzie commented on CASSANDRA-17498: --- If we choose to go this route: [PR|https://github.com/apache/cassandra/pull/1536] [JDK8 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/196/workflows/8fc45738-b815-4a17-8a86-175977d466eb] [JDK11 CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/196/workflows/d4f2bb3c-3978-4362-8601-f6647001b363] > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17474) Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
[
https://issues.apache.org/jira/browse/CASSANDRA-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514789#comment-17514789
]
Brandon Williams commented on CASSANDRA-17474:
--
It appears that slf4j will no longer interpolate an exception directly and
instead interprets it as another argument to print, resulting in the braces and
then the exception on the next line. I've changed this to the exception's
string and that passes.
[Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17474] and
[circle|https://app.circleci.com/pipelines/github/driftx/cassandra/417/workflows/5d0d51fe-fc99-48f8-97e4-ef68e0d24f57].
> Failed to instantiate SLF4J LoggerFactory in Cassandra 3.11.12
> --
>
> Key: CASSANDRA-17474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17474
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Tobias Gustafsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.13
>
> Attachments: logback.xml
>
>
> After upgrading to 3.11.12, Cassandra crashes on startup because of a class
> that cannot be found in slf4j.
> {code}
> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionCache.getBeanDescription(BeanDescriptionCache.java:47)
> at
> ch.qos.logback.core.joran.util.PropertySetter.(PropertySetter.java:68)
> at
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:65)
> at
> ch.qos.logback.core.joran.spi.Interpreter.lookupImplicitAction(Interpreter.java:233)
> at
> ch.qos.logback.core.joran.spi.Interpreter.getApplicableActionList(Interpreter.java:252)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:142)
> at
> ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128)
> at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
> at
> ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
> at
> ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:65)
> at
> ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:140)
> at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
> at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
> at
> org.apache.cassandra.service.CassandraDaemon.(CassandraDaemon.java:117)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.event.LoggingEvent
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
> ... 27 more
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/slf4j/event/LoggingEvent
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.privateGetPublicMethods(Class.java:2902)
> at java.lang.Class.getMethods(Class.java:1615)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionFactory.create(BeanDescriptionFactory.java:35)
> at
> ch.qos.logback.core.joran.util.beans.BeanDescriptionCache.getBeanDescription(BeanDescriptionCache.java:47)
> at
> ch.qos.logback.core.joran.util.PropertySetter.(PropertySetter.java:68)
> at
> ch.qos.logback.core.joran.action.NestedComplexPropertyIA.isApplicable(NestedComplexPropertyIA.java:65)
> at
>
[cassandra-in-jvm-dtest-api] branch dcapwell-patch-1 created (now 2421ce4)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch dcapwell-patch-1 in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git. at 2421ce4 Updated setting newVersion to look up the current version This branch includes the following new commits: new 2421ce4 Updated setting newVersion to look up the current version 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-in-jvm-dtest-api] 01/01: Updated setting newVersion to look up the current version
This is an automated email from the ASF dual-hosted git repository.
dcapwell pushed a commit to branch dcapwell-patch-1
in repository https://gitbox.apache.org/repos/asf/cassandra-in-jvm-dtest-api.git
commit 2421ce42326cfef04044ebf0c2a18076cd064622
Author: dcapwell
AuthorDate: Wed Mar 30 08:57:44 2022 -0700
Updated setting newVersion to look up the current version
---
README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 236e137..eb0bde5 100644
--- a/README.md
+++ b/README.md
@@ -5,7 +5,7 @@ Shared API package for in-JVM distributed tests.
# Publishing snapshot
```
-mvn versions:set -DnewVersion=0.0.2-`git rev-parse --short HEAD`-SNAPSHOT
+mvn versions:set -DnewVersion=`xpath -n -q -e '/project/version/text()'
pom.xml | awk -F- '{print $1}'`-`git rev-parse --short HEAD`-SNAPSHOT
mvn deploy
```
@@ -56,4 +56,4 @@ gpg --verbose --recv-keys --keyserver
hkps://hkps.pool.sks-keyservers.net https://dist.apache.org/repos/dist/release/cassandra/
release
(gpg --list-sigs "" && gpg --armor --export "") >> KEYS
svn commit KEYS -m "Add 's key for releases" # or ask some PMC to
do this for you by opening CASSANDRA jira, like this one:
https://issues.apache.org/jira/browse/CASSANDRA-15534
-```
\ No newline at end of file
+```
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17478) Disallow removal of a DC from system_auth replication settings
[ https://issues.apache.org/jira/browse/CASSANDRA-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514750#comment-17514750 ] Ekaterina Dimitrova commented on CASSANDRA-17478: - Oh nice! Thank you [~brandon.williams], I just linked it also in Butler. > Disallow removal of a DC from system_auth replication settings > -- > > Key: CASSANDRA-17478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17478 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > Time Spent: 40m > Remaining Estimate: 0h > > It's never correct for an operator to remove a DC from system_auth > replication settings while there are currently nodes up in that DC. We should > disallow the ability to manually make this change, as if you need to > decommission a DC you need to remove all the nodes from the cluster before > allowing the replication settings change on system_auth. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17493: -- Test and Documentation Plan: CI build Status: Patch Available (was: Open) https://github.com/apache/cassandra/pull/1529 > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17478) Disallow removal of a DC from system_auth replication settings
[ https://issues.apache.org/jira/browse/CASSANDRA-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514747#comment-17514747 ] Brandon Williams commented on CASSANDRA-17478: -- [~e.dimitrova] that is CASSANDRA-17496 which wasn't linked here but I've done it now. > Disallow removal of a DC from system_auth replication settings > -- > > Key: CASSANDRA-17478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17478 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > Time Spent: 40m > Remaining Estimate: 0h > > It's never correct for an operator to remove a DC from system_auth > replication settings while there are currently nodes up in that DC. We should > disallow the ability to manually make this change, as if you need to > decommission a DC you need to remove all the nodes from the cluster before > allowing the replication settings change on system_auth. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17493: -- Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear Impact(13164) Complexity: Low Hanging Fruit Component/s: Legacy/Core Discovered By: Adhoc Test Reviewers: Paulo Motta Severity: Normal Assignee: Stefan Miklosovic Status: Open (was: Triage Needed) > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17496) Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults
[ https://issues.apache.org/jira/browse/CASSANDRA-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514745#comment-17514745 ] Brandon Williams commented on CASSANDRA-17496: -- +1 > Test Failure: AlterTest.testCreateAlterNetworkTopologyWithDefaults > -- > > Key: CASSANDRA-17496 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17496 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Caused by CASSANDRA-17478 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17478) Disallow removal of a DC from system_auth replication settings
[ https://issues.apache.org/jira/browse/CASSANDRA-17478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514739#comment-17514739 ] Ekaterina Dimitrova commented on CASSANDRA-17478: - Hey [~jmckenzie] , seems like we got a flaky test here. I see it was not in your run failing, but it failed for me with midres on Circle, then locally consistently and now I also saw it in Jenkins: [https://jenkins-cm4.apache.org/job/Cassandra-trunk/1054/testReport/junit/org.apache.cassandra.cql3.validation.operations/AlterTest/testCreateAlterNetworkTopologyWithDefaults_cdc/] Please check it > Disallow removal of a DC from system_auth replication settings > -- > > Key: CASSANDRA-17478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17478 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.1 > > Time Spent: 40m > Remaining Estimate: 0h > > It's never correct for an operator to remove a DC from system_auth > replication settings while there are currently nodes up in that DC. We should > disallow the ability to manually make this change, as if you need to > decommission a DC you need to remove all the nodes from the cluster before > allowing the replication settings change on system_auth. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514716#comment-17514716
]
Sathyanarayanan Saravanamuthu commented on CASSANDRA-17458:
---
So, what's the plan? Should we take this patch? Or create another Jira issue to
find and resolve the issues at other places?
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Labels: patch-available
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17458) Test Failure: org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
[
https://issues.apache.org/jira/browse/CASSANDRA-17458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514706#comment-17514706
]
Benjamin Lerer commented on CASSANDRA-17458:
I had a look at the code and the patch will fix this specific use case but it
looks like CEP-14 introduced similar problems for multiple methods from
QueryProcessor.
> Test Failure:
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie
> ---
>
> Key: CASSANDRA-17458
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17458
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Sathyanarayanan Saravanamuthu
>Priority: Normal
> Labels: patch-available
> Fix For: 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Intermittent failure on
> {{org.apache.cassandra.db.SinglePartitionSliceCommandTest#testPartitionDeletionRangeDeletionTie}}
> for trunk:
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1024/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> [https://ci-cassandra.apache.org/job/Cassandra-trunk/1018/testReport/org.apache.cassandra.db/SinglePartitionSliceCommandTest/testPartitionDeletionRangeDeletionTie/]
> {code:java}
> Failed 1 times in the last 11 runs. Flakiness: 10%, Stability: 90%
> Error Message
> Expected [Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11]] but got [Marker
> INCL_START_BOUND(1, 1)@10/1647704834, Row[info=[ts=11] ]: c1=1, c2=1 | [v=1
> ts=11], Marker INCL_END_BOUND(1, 1)@10/1647704834] expected:<[[[v=1 ts=11]]]>
> but was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73,
> [[v=1 ts=11]],
> org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> Stacktrace
> junit.framework.AssertionFailedError: Expected [Row[info=[ts=11] ]: c1=1,
> c2=1 | [v=1 ts=11]] but got [Marker INCL_START_BOUND(1, 1)@10/1647704834,
> Row[info=[ts=11] ]: c1=1, c2=1 | [v=1 ts=11], Marker INCL_END_BOUND(1,
> 1)@10/1647704834] expected:<[[[v=1 ts=11]]]> but
> was:<[org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@3db1ed73, [[v=1
> ts=11]], org.apache.cassandra.db.rows.RangeTombstoneBoundMarker@1ea92553]>
> at
> org.apache.cassandra.db.SinglePartitionSliceCommandTest.testPartitionDeletionRangeDeletionTie(SinglePartitionSliceCommandTest.java:463)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Standard Output
> INFO [main] 2022-03-19 15:51:43,646 YamlConfigurationLoader.java:103 -
> Configuration location:
> file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> DEBUG [main] 2022-03-19 15:51:43,653 YamlConfigurationLoader.java:124 -
> Loading settings from file:/home/cassandra/cassandra/test/conf/cassandra.yaml
> INFO [main] 2022-03-19 15:51:43,971 Config.java:1119 - Node
> configuration:[allocate_tokens_for_keyspace=null;
> allocate_tokens_for_local_replication_factor=null;
> allow_extra_insecure_udfs=false; all
> ...[truncated 192995 chars]...
> ome/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-37-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-39-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-38-big-Data.db:level=0,
>
> /home/cassandra/cassandra/build/test/cassandra/data/system/local-7ad54392bcdd35a684174e047860b377/nb-40-big-Data.db:level=0,
> ]
> {code}
> Failures can also be hit with CircleCI test multiplexer:
> [https://app.circleci.com/pipelines/github/adelapena/cassandra/1387/workflows/0f37a726-1dc2-4584-86f9-e99ecc40f551]
> CircleCI results show failures on three separate assertions, with a ~3%
> flakiness.
> The same test looks ok in 4.0, as suggested by Butler and [this repeated
> Circle
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1388/workflows/6b69d654-3d19-4f2a-aeb9-dc405c6ddd2b].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514664#comment-17514664
]
Benjamin Lerer commented on CASSANDRA-10537:
I realized that we also need to update the CQLSH auto-completion in
pylib/cqlshlib/cql3handling.py for {{}}. Outside of that the patch
look good to me. :-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514636#comment-17514636 ] Paulo Motta commented on CASSANDRA-17499: - bq. However, we don't have that set of recommended defaults and, instead, every guardrail is disabled by default, so currently the global flag doesn't add that much value. This makes sense. Thanks for the detailed explanation! > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 20m > Remaining Estimate: 0h > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17494) Pre hashed passwords in CQL docs
[ https://issues.apache.org/jira/browse/CASSANDRA-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514620#comment-17514620 ] Andres de la Peña commented on CASSANDRA-17494: --- Sure, I'll take a look. > Pre hashed passwords in CQL docs > > > Key: CASSANDRA-17494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17494 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > CASSANDRA-17334 needs some docs -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17494) Pre hashed passwords in CQL docs
[ https://issues.apache.org/jira/browse/CASSANDRA-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17494: -- Reviewers: Andres de la Peña > Pre hashed passwords in CQL docs > > > Key: CASSANDRA-17494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17494 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > CASSANDRA-17334 needs some docs -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17499) Remove global Guardrails Enable flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514616#comment-17514616
]
Andres de la Peña commented on CASSANDRA-17499:
---
Guardrails can be disabled both individually and globally. The global flag is
disabled by default, and all the new guardrails that have been recently added
are also individually disabled:
{code:java}
guardrails_enabled: false
keyspaces_warn_threshold: -1
keyspaces_fail_threshold: -1
tables_warn_threshold: -1
tables_fail_threshold: -1
{code}
The problem comes when we try to migrate existing properties to guardrails.
Those properties can have a default value, so they are not disabled, for
example:
{code:java}
tombstone_warn_threshold: 1000
tombstone_failure_threshold: 10
{code}
If we transform those properties into guardrails they would be subjected to the
{{guardrails_enabled}} flag. Since that flag is disabled by default, they would
become disabled, breaking compatibility with previous releases where it was
enabled by default.
Some options to deal with this are:
# Do not migrate properties until the next major.
# Set {{guardrails_enabled}} to true by default.
# Get rid of {{{}guardrails_enabled{}}}, as it's proposed here.
# Have two type of guardrails, those using the global enable flag and those
not using it. That feels like overcomplicating things.
The main reason to have that global flag was to provide a set of aggressive,
opinionated defaults for every individual guardrail, and then disable them by
default with the global flag. That way, one could choose to drive with or
without the entire set of recommended guardrails. However, we don't have that
set of recommended defaults and, instead, every guardrail is disabled by
default, so currently the global flag doesn't add that much value.
> Remove global Guardrails Enable flag
>
>
> Key: CASSANDRA-17499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17499
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Savni Nagarkar
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This ticket removes the global Guardrails enable flag. Currently the flag
> turns all Guardrails on and off regardless of the individual setting of the
> guardrail property. This presents a problem for maximum replication factor
> and minimum replication factor configurations which will soon be moved to
> guardrails. Those configurations will always need to be enabled so no
> problems arise as Cassandra users create keyspaces. This ensures all
> Guardrail properties follow the same enable / disable procedure.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17499: -- Epic Link: CASSANDRA-17146 > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514322#comment-17514322 ] Stefan Miklosovic edited comment on CASSANDRA-17495 at 3/30/22, 9:09 AM: - [~jmckenzie] I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? I think you can grant / revoke dropping too. For RENAME we have GRANT / REVOKE MODIFY. More to it, if this is needed for some "bulk operation" to cover all users, all it requires to have all these users in the same role: 1) CREATE ROLE somerole; 2) GRANT somerole TO someuser; 3) REVOKE ALTER ON ks1.tb1 FROM solerole; Even for all keyspaces for all such users in that role: 4) REVOKE ALTER ON ALL KEYSPACES FROM developers; I just dont see the justification why we need this (yet). was (Author: smiklosovic): I was looking at this PR in GH and I was wondering how is this different from GRANT ALTER ON TABLE ks1.tb1 TO ... and REVOKE ALTER ON ks1.tb1 FROM ? I think you can grant / revoke dropping too. For RENAME we have GRANT / REVOKE MODIFY. More to it, if this is needed for some "bulk operation" to cover all users, all it requires to have all these users in the same role: 1) CREATE ROLE somerole; 2) GRANT somerole TO someuser; 3) REVOKE ALTER ON ks1.tb1 FROM solerole; Even for all keyspaces for all such users in that role: 4) REVOKE ALTER ON ALL KEYSPACES FROM developers; I just dont see the justification why we need this (yet). > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514529#comment-17514529
]
Berenguer Blasi commented on CASSANDRA-17140:
-
Just adding a note to myself here and to whoever else it might be useful
{noformat}
Error:
ID mismatch while trying to reprepare (expected
b'6adce641dda5efd3e3c427f94a11e358', got b'eac9d72796ebeeb41ba1bbb906493a91').
This prepared statement won't work anymore. This usually happens when you run a
'USE...' query after the statement was prepared.
4.0 repro
pytest -vv --log-cli-level=DEBUG --junit-xml=nosetests.xml
--junit-prefix=dtest-upgrade -s --cassandra-dir=../17140
--execute-upgrade-tests-only --upgrade-target-version-only
--upgrade-version-selection all
upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_current_3_0_x_To_indev_4_0_x::test_rolling_upgrade_with_internode_ssl
3.11 + 4.0 repro
pytest -vv --log-cli-level=DEBUG --junit-xml=nosetests.xml
--junit-prefix=dtest-upgrade -s --cassandra-dir=../17140
--execute-upgrade-tests-only --upgrade-target-version-only
--upgrade-version-selection all
upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD::test_rolling_upgrade_with_internode_ssl
{noformat}
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17501) Security admin separation of duties
[
https://issues.apache.org/jira/browse/CASSANDRA-17501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17501:
Description:
This ticket is about enabling a sort of security admin role.
Think of a hospital with patient data which is very sensitive information. IT
should be able to grant/revoke/restrict access to the data without having
access to the data itself. This is the clear separation of duties between
admins and users of the database we're after.
An example is along the lines:
{noformat}
As a superuser:
CREATE KEYSPACE patientdata …;
CREATE ROLE security_admin;
GRANT security_admin TO admin_guy;
GRANT AUTHORIZE FOR SELECT, MODIFY, EXECUTE ON patientdata TO security_admin;
RESTRICT SELECT, MODIFY, EXECUTE ON KEYSPACE patientdata TO security_admin;
As a security admin:
GRANT SELECT ON patientdata TO new_nurse;
GRANT SELECT, MODIFY ON patientdata TO doctor_house;
{noformat}
Original idea of [~snazy]
was:
This ticket is about enabling a sort of security admin role.
Think of a hospital with patient data which is very sensitive information. IT
should be able to grant/revoke/restrict access to the data without having
access to the data itself. This is the clear separation of duties between
admins and users of the database we're after.
An example is along the lines:
{noformat}
As a superuser:
CREATE KEYSPACE patientdata …;
CREATE ROLE security_admin;
GRANT security_admin TO admin_guy;
GRANT AUTHORIZE FOR
SELECT, MODIFY, EXECUTE ON patientdata TO security_admin;
RESTRICT SELECT, MODIFY, EXECUTE ON KEYSPACE patientdata TO security_admin;
As a security admin:
GRANT SELECT ON patientdata TO new_nurse;
GRANT SELECT, MODIFY ON patientdata TO doctor_house;
{noformat}
Original idea of [~snazy]
> Security admin separation of duties
> ---
>
> Key: CASSANDRA-17501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17501
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Priority: Normal
>
> This ticket is about enabling a sort of security admin role.
> Think of a hospital with patient data which is very sensitive information. IT
> should be able to grant/revoke/restrict access to the data without having
> access to the data itself. This is the clear separation of duties between
> admins and users of the database we're after.
> An example is along the lines:
> {noformat}
> As a superuser:
> CREATE KEYSPACE patientdata …;
> CREATE ROLE security_admin;
> GRANT security_admin TO admin_guy;
> GRANT AUTHORIZE FOR SELECT, MODIFY, EXECUTE ON patientdata TO security_admin;
> RESTRICT SELECT, MODIFY, EXECUTE ON KEYSPACE patientdata TO security_admin;
> As a security admin:
> GRANT SELECT ON patientdata TO new_nurse;
> GRANT SELECT, MODIFY ON patientdata TO doctor_house;
> {noformat}
> Original idea of [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17501) Security admin separation of duties
Berenguer Blasi created CASSANDRA-17501:
---
Summary: Security admin separation of duties
Key: CASSANDRA-17501
URL: https://issues.apache.org/jira/browse/CASSANDRA-17501
Project: Cassandra
Issue Type: New Feature
Components: Feature/Authorization
Reporter: Berenguer Blasi
This ticket is about enabling a sort of security admin role.
Think of a hospital with patient data which is very sensitive information. IT
should be able to grant/revoke/restrict access to the data without having
access to the data itself. This is the clear separation of duties between
admins and users of the database we're after.
An example is along the lines:
{noformat}
As a superuser:
CREATE KEYSPACE patientdata …;
CREATE ROLE security_admin;
GRANT security_admin TO admin_guy;
GRANT AUTHORIZE FOR
SELECT, MODIFY, EXECUTE ON patientdata TO security_admin;
RESTRICT SELECT, MODIFY, EXECUTE ON KEYSPACE patientdata TO security_admin;
As a security admin:
GRANT SELECT ON patientdata TO new_nurse;
GRANT SELECT, MODIFY ON patientdata TO doctor_house;
{noformat}
Original idea of [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17494) Pre hashed passwords in CQL docs
[ https://issues.apache.org/jira/browse/CASSANDRA-17494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514463#comment-17514463 ] Berenguer Blasi commented on CASSANDRA-17494: - [~adelapena] this shold be a quick one to review for you as you already reviewed the parent issue :-) > Pre hashed passwords in CQL docs > > > Key: CASSANDRA-17494 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17494 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.1 > > > CASSANDRA-17334 needs some docs -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
