[
https://issues.apache.org/jira/browse/CASSANDRA-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880018#comment-17880018
]
Stefan Miklosovic commented on CASSANDRA-19828:
-----------------------------------------------
[~frankgh] "dynamic" most probably translates to "guardrail". We want to ship
this feature to 4.0 up to I-do-not-know-exactly-what. There are not guardrails
in 4.0, only from 4.1 up so I am all ears what to put into 4.0 then.
We agreed in CASSANDRA-19556 that it is not going to be introduced into 5.0.0
because it was too late so we agreed that CASSANDRA-19556 will be in trunk
only. CASSANDRA-19556 is about the introduction of two guardrails - ddl_enabled
and dcl_enabled. The first one enables schema modifications and the second one
enables authorization statements.
What [~samt] suggested in CASSANDRA-19556 was that we could have something
similar to what CASSANDRA-19556 introduces for lower branches as well but we
can not port CASSANDRA-19556 to 4.0/4.1+ because these are completely new
features and we can not add completely new features into old branches.
The rationale behind the introduction of _something similar which resembles
CASSANDRA-19556_ into 4.0/4.1 is that it would be nice if we had a way to
forbid schema modifications while we want to upgrade the cluster so an operator
is sure that schema is not changing while an upgrade is in process. So, the
next best thing when CASSANDRA-19556 is not going to be shipped in 4.0+ is to
introduce _something_ which disables that, just to remove it in trunk and
replace it with more robust CASSANDRA-19556.
Few observations:
1) If you wanted to have it dynamic, it can not be a guardrail in 4.0 because
guardrail framework was implemented in 4.1 for the first time.
2) We would probably have some MBean method on StorageService in 4.0 and
guardrail in 4.1 and 5.0 (???) and then we would not ship this in trunk because
we go to replace that with CASSANDRA-19556 (does this all make sense to you?
That is pretty chaotic IMHO.)
3) We need to deprecate alter_table_enabled guardrail in 5.0.1 which is another
guardrail we have in this space which becomes obsolete when CASSANDRA-19556 is
merged (and alter_table_enabled will be removed from trunk then).
To be somewhat consistent and support schema modification disablement in
4.0+but < 5.1 and you want that to be dynamic, we might just introduce an MBean
method on StorageService like
StorageServiceMBean.enableSchemaModifications(boolean) by which you would
control this dynamically but then please beware that we are changing public
interfaces in patch releases.
Looking forward to your answer!
> Introduce system property to prevent schema modifications
> ---------------------------------------------------------
>
> Key: CASSANDRA-19828
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19828
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Core
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.0.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This is the first ticket as described here (1) in order to eventually merge
> CASSANDRA-19556.
> (1)
> https://issues.apache.org/jira/browse/CASSANDRA-19556?focusedCommentId=17856432&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17856432
> I created this ticket to have type "New Feature" but this needs to be merged
> to 4.0, 5.0 for the purposes of CASSANDRA-19556. "Task" would probably make
> it too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
