[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635858#comment-17635858 ] Andres de la Peña commented on CASSANDRA-17967: --- Committed to trunk as [9f99e72aae812b86d277883601450bc0e7bb9463|https://github.com/apache/cassandra/commit/9f99e72aae812b86d277883601450bc0e7bb9463]. Thanks for the reviews. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635698#comment-17635698 ] Berenguer Blasi commented on CASSANDRA-17967: - Yep, now things align +1 thx for the work! > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635334#comment-17635334
]
Andres de la Peña commented on CASSANDRA-17967:
---
I have rebased and re-run CI, including {{SchemaTest}} and
{{OfflineTokenAllocatorGenerationsTest}} into the repeated tests:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1972]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2494/workflows/1e86e52e-d12c-42ab-ae20-f47c51cbd0a6]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2494/workflows/d8e7768d-deb8-43b3-b3b3-b5d60b2bdced]|
All the timeouts except the one in {{SchemaTest#schemaReset}} are gone. That
one isn't shown on Butler, but it can be reproduced on trunk with Circle:
[https://app.circleci.com/pipelines/github/adelapena/cassandra/2495/workflows/d92a7794-091a-4ea0-92c0-cd59a712c0d3]
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635161#comment-17635161 ] Berenguer Blasi commented on CASSANDRA-17967: - The CI timeouts are suspicious. I would rerun them at least bc I checked and they don't align to jenkins. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634957#comment-17634957
]
Andres de la Peña commented on CASSANDRA-17967:
---
I have realized just before committing that the call to
{{View#getSelectStatement}} is an internal call, as it's specified on its
javaDoc. As such, its {{ClientState}} should be
{{{}ClientState.forInternalCalls{}}}, so it's excluded from guardrail checks.
Incidentally it doesn't seem to hit any guardrail on its operation, but we
should nevertheless use the correct {{ClientState}} in case we add other
guardrails that do affect those internal queries in the future.
Patched and running CI again:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1972]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2492/workflows/9f3f1516-ed04-4772-8973-55c1ee498cbb]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2492/workflows/9cc458ef-92f4-4778-a3d5-23ba57d05483]|
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634832#comment-17634832 ] Andres de la Peña commented on CASSANDRA-17967: --- Created CASSANDRA-18054 for appending contact details. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634666#comment-17634666 ] Berenguer Blasi commented on CASSANDRA-17967: - LGTM. Was the ticket of adding a contact email or similar created? > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634385#comment-17634385 ] Andres de la Peña commented on CASSANDRA-17967: --- Thanks for the reviews. I have applied [Josh's suggestion about using a ternary operator|https://github.com/apache/cassandra/pull/1972#discussion_r1019504964], squashed, rebased and run pre-commit CI: ||PR||CI|| |[trunk|https://github.com/apache/cassandra/pull/1972]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2487/workflows/d335394b-d976-43b2-bab7-869592d4d154] [j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2487/workflows/c17d75a4-92ba-43eb-9436-26dbfa96cef0]| > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631861#comment-17631861 ] Josh McKenzie commented on CASSANDRA-17967: --- +1 in the PR here as well. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 40m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631649#comment-17631649 ] Berenguer Blasi commented on CASSANDRA-17967: - Yep you have the +1 in the PR :) > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 40m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631636#comment-17631636 ] Andres de la Peña commented on CASSANDRA-17967: --- [~Bereng] are we ready to commit? [~jmckenzie] [~oramad] anything else to add? If it looks good I'll commit this and create a follow ticket for adding the configurable "contact x for help" part of the user-facing error messages. That IMO should appear at the end of any user-facing error message, not only on guardrail messages. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Time Spent: 1h 40m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629051#comment-17629051 ] Andres de la Peña commented on CASSANDRA-17967: --- CI with some additional testing for the proposed changes: > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629002#comment-17629002
]
Andres de la Peña commented on CASSANDRA-17967:
---
[Here|https://github.com/apache/cassandra/compare/trunk...adelapena:17967-trunk]
is a draft patch.
#
[Here|https://github.com/adelapena/cassandra/commit/3354f1339fc3f75cdcadd8f654a5ce2ffd441cf4]
it adds a brief reason of AF is pernicious to the documentation of the
{{allow_filtering_enabled}} property in {{cassandra.yaml}}:
{code:java}
# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
# ALLOW FILTERING can potentially visit all the data in the table and have
unpredictable performance.
# allow_filtering_enabled: true{code}
I guess that any user finding the guardrail violation error would land there,
so it seems a good place to document the reason for disabling it. We should
probably add similar reasons for all other guardrails and guardrail-like
properties.
#
[Here|https://github.com/adelapena/cassandra/commit/852afe334318b86483a916c6533c876a486c3045]
it adds a "reason" optional string attribute to every guardrail, so it's
printed right after the guardrail violation error message. For the AF guardrail
the full message is:
{code:java}
> SELECT * FROM k.t WHERE v = 2 ALLOW FILTERING;
Guardrail allow_filtering violated: Querying with ALLOW FILTERING is not
allowed. ALLOW FILTERING can potentially visit all the data in the table and
have unpredictable performance.{code}
Other guardrails don't use this "reason" property, but we should probably start
using them.
#
[Here|https://github.com/adelapena/cassandra/commit/b8ebb7bbfc6f8c9c3247bca70a887f52c64e503f]
it makes the message for missing AF depend on whether the guardrail is enabled
or not. So if a query without AF requires filtering it prints exactly the same
message as before, which is:
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have
unpredictable performance. If you want to execute this query despite the
performance unpredictability, use ALLOW FILTERING{code}
But if the guardrail is disabling AF, the message is
{code:java}
> SELECT * FROM k.t WHERE v = 0;
Cannot execute this query as it might involve data filtering and thus may have
unpredictable performance. Executing this query despite the performance
unpredictability with ALLOW FILTERING has been disabled by the
allow_filtering_enabled property in cassandra.yaml{code}
The commit is a bit noisy due to the need to make the {{ClientState}} available
to {{{}StatementRestrictions{}}}.
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622836#comment-17622836 ] Sarma Pydipally commented on CASSANDRA-17967: - agree with [~jmckenzie] > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622650#comment-17622650
]
Josh McKenzie commented on CASSANDRA-17967:
---
{quote}cassandra itself gives a very convoluted error message which mostly
suggests to use "ALLOW FILTERING" clause. So that is the main reason we are
going towards this new guardrail - so having a custom message is not such a bad
idea.
{quote}
I agree with the problem statement and disagree with the proposed solution. We
should clean up our default error message + make it more clear in the guardrail
message why we think ALLOW FILTERING is by default a bad idea, perhaps even
linking to documentation that helps educate the user on why and how ALLOW
FILTERING doesn't scale.
Asking each operator or user to shore up our insufficient base error messaging
isn't enough in my opinion. We can do better. :)
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622147#comment-17622147
]
Benjamin Lerer commented on CASSANDRA-17967:
[~brandon.williams] proposal make sense to me.
{quote}Pretty sure [~blerer] spent some cycles on working on mapping error
codes at some point; there's so much in the system at this point that trying to
"boil the ocean" on the topic isn't viable.\{quote}
I effectively spent a couple of months trying to come up with a solution for
error codes and error messages. At this stage it is really a hard problem to
solve.
Regarding custom messages, we can allow additional information to be passed to
message but not more in my opinion. I have seen too many bugs where the only
information provided was a simple error message. If the error messages start to
be custom ones it will become impossible for us to track down where the error
is coming from.
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620670#comment-17620670 ] Brandon Williams commented on CASSANDRA-17967: -- I wouldn't be against changing [the error|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java#L53] to not mention AF if the guardrail has it disabled. It doesn't really make sense to mention something that can't be used. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620665#comment-17620665 ] Sarma Pydipally commented on CASSANDRA-17967: - [~jmckenzie] allow filtering is the one of the most misused + misunderstood options in my opinion. every time a user runs an inappropriate select query : cassandra itself gives a very convoluted error message which mostly suggests to use "ALLOW FILTERING" clause. So that is the main reason we are going towards this new guardrail - so having a custom message is not such a bad idea. we can wait for few others to chime in with their opinions. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620570#comment-17620570 ] Josh McKenzie commented on CASSANDRA-17967: --- Opening Pandora's Box when you start talking about error codes. :) (see CASSANDRA-3979 for instance). Pretty sure [~blerer] spent some cycles on working on mapping error codes at some point; there's so much in the system at this point that trying to "boil the ocean" on the topic isn't viable. My .02: # A global "contact this email address if you'd like an exception to this guardrail" that's operator configurable sounds clean and simple and provides a lot of value # I don't actually see the value in customizing the error messages on guardrails; if the error messages we currently fire aren't descriptive of the issue and don't properly educate the user we need to update and improve them # We should talk about error codes on the dev ML so we can all publicly rant about them together. ;) > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620484#comment-17620484 ] Sarma Pydipally commented on CASSANDRA-17967: - I agree that we should not have dedicated parameter for custom error message for allow_filtering. But if we can come up with a generic framework, which can be used for all other guardrails - i think will be helpful. I just tagged this feature for 4.1 - but it can wait for a better design and include it in 4.2 or 5.x - when it is ready. Please keep this ticket open and we can discuss further or how to design this - if it requires a deeper discussion with experts. Also about error codes : I am not very familiar with internal process of how cassandra handles internal exceptions, but it will be wonderful if there is a framework which has standard error codes and associated short_error_message and detailed_error_message info ... then we can decide if it dumps it on console or it is written into logs. but having such error codes will allow the framework to support for custom error messages. Any ideas ? > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[
https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620175#comment-17620175
]
Andres de la Peña commented on CASSANDRA-17967:
---
Indeed 4.1 is in feature freeze, and whatever we do would be for 5.0.
I think that if we are going to add custom error messages it should be done for
all guardrails, and not only for {{allow_filtering_enabled}}. Enable flags are
probably the easy case because they don't print the values that triggered the
value nor any limit threshold. Other guardrails use this kind of format:
{code}
format("Cannot have more than %s tables, aborting the creation of table %s",
threshold, what);
{code}
Maybe we should allow (or expect) those placeholders in the config property.
I don't see a lot of value in adding a property for just replacing "Querying
with ALLOW FILTERING is not allowed" by something like "STOP using
allow_filtering clause". Also, since we don't have fine-grained error codes for
this kind of exceptions, customizing error messages could make it harder to
identify the error and look for info about it. I guess that keeping the
"Guardrail allow_filtering violated" part and customizing the details after
that could help with identification.
However, adding the generic "Email with your cluster name
and use-case if you would like to apply for a specific exception" at the end of
the error message sounds quite useful to me. That customizable string could be
the same for all user-facing errors, not only guardrails, and it could be
defined as a single global property.
> Guardrail: allow_filtering_custom_error_message
> ---
>
> Key: CASSANDRA-17967
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17967
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Sarma Pydipally
>Priority: Normal
>
> in Apache Cassandra Release Version 4.1 :
> with "allow_filtering_enabled: false" option under guardrails :
> regular users cannot run queries with allow filtering clause in SELECT
> commands. Users get following error message :
> :1:InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is
> not allowed"
> I propose for a new parameter in conf file : something like :
> allow_filtering_custom_error_message and allow cluster operators to configure
> custom message
> so if someone runs a SELECT command along with "ALLOW FILTERING"
> it should print ERROR : InvalidRequest:code=2202:message="STOP using
> allow_filtering clause"
> so this will allow the operators to stop users from running allow filtering
> as well as give them to configure a custom error message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619884#comment-17619884 ] Ekaterina Dimitrova commented on CASSANDRA-17967: - [~oramad] reached out to me while I was away and I told him I think I saw already a guardrail for this but I did not have access to computer, etc at this point. I think he was looking for this functionality in 4.1(also stated in the description). So we have a few things going on here: * 4.1 is already in feature freeze, so we cannot add it there, unfortunately. But we can look into what we have in trunk - 5.0 * trunk already has added allow_filtering_enabled as part of CASSANDRA-17370. That is the one [~jmckenzie], [~smiklosovic] and I had in mind * I guess we can keep this ticket for any further enhancements if we plan on any and update the description and get it out of triage of course [~oramad], this is your ticket, let me know what you think :-) > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619809#comment-17619809 ] Stefan Miklosovic commented on CASSANDRA-17967: --- +1 to what [~jmckenzie] says. This might be also used for upcoming password guardrail (if we happen to implement it) to put there some emails to security folks etc or something custom completely (links to docs about password policies etc). > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619807#comment-17619807 ] Josh McKenzie commented on CASSANDRA-17967: --- I think the question you're really pointing to is: Should we augment the Guardrails framework to allow operators to specify custom error messages? [~adelapena] - have you given this any thought? My initial reaction is that yeah, this is probably pretty useful. Being able to have an error message that says something like "Feature X is disabled because it causes problems Y. Email with your cluster name and use-case if you would like to apply for a specific exception" or something could be pretty useful. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Priority: Normal > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
