[
https://issues.apache.org/jira/browse/CASSANDRA-19828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880018#comment-17880018
]
Stefan Miklosovic edited comment on CASSANDRA-19828 at 9/7/24 8:13 AM:
-----------------------------------------------------------------------
[~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) If we introduced guardrails in 4.1 and 5.0, then these guardrails would be
deprecated in trunk because we replaced that by CASSANDRA-19556. So, we
introduce them in 4.1.x and 5.0.1 and we remove them in 5.1 - we just removed
them without any deprecation period, we can not do that.
4) 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. Since it is not a guardrail and this would not be
introduced in trunk, we could just keep this method in 4.0 / 4.1 / 5.0 for ever
without any deprecation but at the same time I am not sure if we can introduce
it in trunk because that will be replaced by CASSANDRA-19556.
So, in trunk we would end up with a method on MBean as well as with two new
guardrails from CASSANDRA-19556. I do not like that we have two ways doing the
same thing so in trunk, the MBean method would need to internally enable /
disable new guardrails we introduced in CASSANDRA-19556.
Looking forward to your answer!
was (Author: smiklosovic):
[~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) If we introduced guardrails in 4.1 and 5.0, then these guardrails would be
deprecated in trunk because we replaced that by CASSANDRA-19556. So, we
introduce them in 4.1.x and 5.0.1 and we remove them in 5.1 - we just removed
them without any deprecation period, we can not do that.
4) 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. Since it is not a guardrail and this would not be
introduced in trunk, we could just keep this method in 4.0 / 4.1 / 5.0 for ever
without any deprecation but at the same time I am not sure if we can not
introduce it in trunk because that will be replaced by CASSANDRA-19556.
So in trunk we would end up with a method on MBean as well as with two new
guardrails from CASSANDRA-19556. I do not like that we have two ways doing the
same thing so in trunk, the MBean method would need to internally enable /
disable new guardrails we introduced in CASSANDRA-19556.
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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
