[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845734#comment-17845734
]
Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:12 PM:
------------------------------------------------------------------------
The decision about putting this in 5.0-rc/beta2 was made based on this answer
on the ML (1) where Josh said that he would make an exception:
_if you could get this patch in before we GA'd, I'd personally support making
an exception for it._
Hence I went ahead.
I still think that this makes sense to include in 5.0.0 GA. If we do not, then
the situation we find ourselves in post GA is that we will have
"alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is
the path forward?
If we do not do this right now, replacing alter_table_enabled with ddl_enabled,
then 5.0.0 will be the only release which will include alter_table_enabled
because if ddl_enabled is introduced then alter_table_enabled does not make
sense to exist anymore. (Please go over the ML thread and my initial email
where I go over all possibilities we have).
I would rather not release anything with alter_table_enabled than to make it
more problematic / questionable how we are actually going to get rid of it post
GA because of backward compatibility etc. It just does not make sense to me to
introduce something we know will have little value once it is out and we know
we want to replace it. Are we OK to drop a guardrail rule just like that? What
is the policy?
(1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl]
was (Author: smiklosovic):
The decision about putting this in 5.0-rc/beta2 was made based on this answer
on the ML (1) where Josh said that he would make an exception:
_if you could get this patch in before we GA'd, I'd personally support making
an exception for it._
Hence I went ahead.
I still think that this makes sense to include in 5.0.0 GA. If we do not, then
the situation we find ourselves in post GA is that we will have
"alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is
the path forward?
If we do not do this right now, replacing alter_table_enabled with ddl_enabled,
then 5.0.0 will be the only release which will include alter_table_enabled
because if ddl_enabled is introduced then alter_table_enabled does not make
sense to exist anymore. (Please go over the ML thread and my initial email
where I go over all possibilities we have).
I would rather not release anything with alter_table_enabled than to make it
more problematic / questionable how are we actually going to get rid of it post
GA because of backward compatibility etc. It just does not make sense to me to
introduce something we know will have little value once it is out and we know
we want to replace it. Are we OK to drop a guardrail rule just like that? What
is the policy?
(1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl]
> 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: 1.5h
> 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
