[
https://issues.apache.org/jira/browse/CASSANDRA-19553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17836278#comment-17836278
]
Stefan Miklosovic edited comment on CASSANDRA-19553 at 4/11/24 5:01 PM:
------------------------------------------------------------------------
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:java}
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.
was (Author: smiklosovic):
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 = '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
