[jira] [Commented] (CASSANDRA-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836519#comment-17836519
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
I think that tuple approach for thresholds vtable is actually better, because
JMX method / config methods for thresholds accept always two parameters as well
- warn and fail. If we were to set it independently, then it would violate how
we do that on JMX level too, basically. Hence I think that it is better if we
just copy what is already in place and modeling this by a tuple seems to be
pretty handy. That would not require to make apply method non final as well.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836278#comment-17836278
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
I'll park this ticket for a while as I am done (minus tests) and this might
receive first round of reviews, I want to have an agreement on the approach.
for warning / failure thresholds, there are two columns, warn and fail, but it
would be great if these thresholds are set together at once. When we update a
column in a vtable, I get just that column, I do not have any visibility what
other column is set to. So when I have "fail" set to 10 and "warn" set to 20,
then this is a valid CQL but it does not make sense on guardrail level.
What I did in system_guardrails.thresholds table is that I made apply method
non final to get all row to operate on.
I think this is a no-no and only other approach I can think of is to use a
tuple like this:
{code:java}
cqlsh> select * from system_guardrails.thresholds_on_tuple ;
name | value
---+--
collection_size | (0, 0)
column_value_size | (-1, -1)
columns_per_table | (-1, -1)
fields_per_udt | (-1, -1)
in_select_cartesian_product | (-1, -1)
items_per_collection | (-1, -1)
keyspaces | (-1, -1)
local_data_disk_usage | (-1, -1)
materialized_views_per_table | (-1, -1)
maximum_replication_factor | (-1, -1)
maximum_timestamp | (0, 0)
minimum_replication_factor | (-1, -1)
minimum_timestamp | (0, 0)
page_size | (-1, -1)
partition_keys_in_select | (-1, -1)
partition_size | (0, 0)
partition_tombstones | (-1, -1)
sai_sstable_indexes_per_query | (32, -1)
secondary_indexes_per_table | (-1, -1)
tables | (-1, -1)
vector_dimensions | (-1, -1)
cqlsh> update system_guardrails.thresholds_on_tuple set value = (10, 20) where
name = 'vector_dimensions';
cqlsh> select value from system_guardrails.thresholds_on_tuple where name =
'vector_dimensions'; value
--
(10, 20)
{code}
Values guardrails look like this:
{code}
cqlsh> select * from system_guardrails.values ;
name | disallowed | ignored | warned
--++-+
read_consistency_levels | {} |{} | {}
table_properties | {} |{} | {}
write_consistency_levels | {} |{} | {}
(3 rows)
cqlsh> update system_guardrails.values set warned = {'EACH_QUORUM', 'ALL'}
where name = 'read_consistency_levels';
(3 rows)
cqlsh> select warned from system_guardrails.values where name =
'read_consistency_levels';
warned
{'ALL', 'EACH_QUORUM'}
(1 rows)
{code}
I think we are fully covered.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name =
[jira] [Commented] (CASSANDRA-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836130#comment-17836130
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
for guardrail type of "Predicates", we have only replicaDiskUsage guardrail.
What it does is that it guards if replicas for a write do not have disk usages
above some threshold and I do think this is applicable to be settable/gettable
from a vtable.
We have PercentageThreshold of name localDataDiskUsage which is subtype of
Threshold, that tracks warn and fail levels for a node a CQL query was executed
against. That one we do show to a user and she can modify it.
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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-19553) get/set guardrails configuration via CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836121#comment-17836121
]
Stefan Miklosovic commented on CASSANDRA-19553:
---
Added enabled flags:
{code}
cqlsh> select * from system_views.guardrails_enable_flags ;
name | value
--+---
allow_filtering | True
alter_table | True
bulk_load_enabled | True
compact_tables | True
drop_keyspace_enabled | True
drop_truncate_table_enabled | True
group_by | True
intersect_filtering_query | True
non_partition_restricted_index_query_enabled | True
read_before_write_list_operations | True
secondary_indexes | True
simplestrategy | True
uncompressed_tables_enabled | False
user_timestamps | True
zero_ttl_on_twcs | True
(15 rows)
cqlsh> update system_views.guardrails_enable_flags SET value = false where name
= 'group_by';
{code}
{code}
INFO [Native-Transport-Requests-1] 2024-04-11 13:15:51,861
GuardrailsOptions.java:998 - Updated group_by_enabled from true to false
{code}
{code}
cqlsh> select value from system_views.guardrails_enable_flags where name =
'group_by';
value
---
False
(1 rows)
{code}
> get/set guardrails configuration via CQL
>
>
> Key: CASSANDRA-19553
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19553
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In CASSANDRA-19552, there is a patch which modifies guardrails via nodetool
> and via reflection.
> I think that it will be better if we do that via CQL.
> So far, I have this:
> {code}
> cqlsh> select * from system_views.guardrails_threshold ;
> name | fail | warn
> ---+---+---
>collection_size | 0 | 0
> column_value_size |-1 |-1
> columns_per_table |-1 |-1
> fields_per_udt |-1 |-1
>in_select_cartesian_product |-1 |-1
> items_per_collection |-1 |-1
> keyspaces |-1 |-1
> materialized_views_per_table |-1 |-1
> maximum_replication_factor |-1 |-1
> maximum_timestamp | 0 | 0
> minimum_replication_factor |-1 |-1
> minimum_timestamp | 0 | 0
> page_size |-1 |-1
> partition_keys_in_select |-1 |-1
> partition_size | 40960 | 20480
> partition_tombstones |-1 |-1
> sai_sstable_indexes_per_query |-1 |32
>secondary_indexes_per_table |-1 |-1
> tables |-1 |-1
> vector_dimensions |-1 |-1
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 16, fail = 20
> where name = 'sai_sstable_indexes_per_query';
> {code}
> {code}
> cqlsh> select * from system_views.guardrails_threshold where name =
> 'sai_sstable_indexes_per_query';
> name | fail | warn
> ---+--+--
> sai_sstable_indexes_per_query | 20 | 16
> {code}
> {code}
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_warn_threshold from 32 to 16
> INFO [Native-Transport-Requests-1] 2024-04-11 11:51:24,483
> GuardrailsOptions.java:998 - Updated
> sai_sstable_indexes_per_query_fail_threshold from -1 to 20
> {code}
> {code}
> cqlsh> update system_views.guardrails_threshold SET warn = 10, fail = 5 where
> name = 'sai_sstable_indexes_per_query';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="The
> warn threshold 10 for sai_sstable_indexes_per_query_warn_threshold should be
> lower than the fail threshold 5"
> {code}
> We can easily extend this to EnableFlag guardrails for which we would
> dedicate a separate table (system_views.guadrails_flag).
> Other guardrail types are being investigated.
--
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
