[ 
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843327#comment-17843327
 ] 

Stefan Miklosovic commented on CASSANDRA-19593:
-----------------------------------------------

I took CEP-24, applied CASSANDRA-19553 and I integrated with with TCM. So it 
behaves like this:

{code}
cqlsh> select * from system_guardrails.flags where name = 'simplestrategy';

 name           | value
----------------+-------
 simplestrategy | True
{code}

so lets disable that ... 

{code}
cqlsh> update system_guardrails.flags set value = false where name = 
'simplestrategy';
cqlsh> select * from system_guardrails.flags where name = 'simplestrategy';

 name           | value
----------------+-------
 simplestrategy | False
{code}

in the logs:

{code}
INFO  [GlobalLogFollower] 2024-05-03 21:18:27,578 LocalLog.java:493 - Enacted 
EXECUTED {Flag{name='simplestrategy', flag=false}}. New tail is Epoch{epoch=9}
INFO  [GlobalLogFollower] 2024-05-03 21:18:27,579 GuardrailsOptions.java:1089 - 
Updated simplestrategy_enabled from true to false
{code}

What happens is that this is integrated with TCM so this setting survives 
restart, after it is restarted, that setting is still false.

Obviously, this will be false on every node in the cluster so there is just one 
CQL command to drive all guardrails, globally, for whole cluster.

This is very soon to open this ticket for a review. I think there is still 
unknowns and to-dos but TCM poc seems to be viable.

Few things:

I do not want to commit guardrail transformation when such configuration would 
be forbidden. For example, when I set fail threshold lower than warn threshold, 
I should not commit this at all and I should detect this before committing. 
This is not easy to do because we would need to validate the guardrail before 
actually executing that. Because if the guardrail is executed as part of the 
validation / in respective flag vtable, then I would run through that logic for 
the second time in the post-commit listener.



> Transactional Guardrails
> ------------------------
>
>                 Key: CASSANDRA-19593
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Feature/Guardrails, Transactional Cluster Metadata
>            Reporter: Stefan Miklosovic
>            Assignee: Stefan Miklosovic
>            Priority: Normal
>             Fix For: 5.x
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is 
> getting into pretty nice shape and we might start to investigate how to do 
> this.



--
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

Reply via email to