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

Sam Tunnicliffe commented on CASSANDRA-19556:
---------------------------------------------

[~mck] this certainly isn't critical for 5.1/6.0, my comment was just intended 
as a counterpoint to illustrate why it might but useful in a 5.0.x

To that point, I'd definitely think about adding _something_ to minors in 
branches with upgrade paths to current trunk. Not an actual guardrail, just a 
system property or similar to optionally disable certain operations immediately 
prior to upgrade. If we did go down that route, there is some precedent from 
back in the day for mandating a minimum minor version prior to a major upgrade 
(from {{{}NEWS.txt{}}}):
{code:java}
Upgrade to 3.0 is supported from Cassandra 2.1 versions greater or equal to 
2.1.9,
or Cassandra 2.2 versions greater or equal to 2.2.2. 
{code}
but like I said, this isn't critical for upgrading to current trunk and I'm 
definitely not advocating for anything in 5.0-rc

> Add guardrail to block DDL/DCL queries and replace alter_table_enabled 
> guardrail
> --------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-19556
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Feature/Guardrails
>            Reporter: Yuqi Yan
>            Assignee: Yuqi Yan
>            Priority: Normal
>             Fix For: 5.0-rc, 5.x
>
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created 
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op 
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The 
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if 
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. 
> at startup, which is no-op but will be blocked by this guardrail and failed 
> to start.
>  
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>  



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