> they have to turn off a node, set the property and turn it back on. This is > not optimal We have quite a few other features that have this same paradigm to disable/enable them. Is there a reason it's worse in this case than those, at least on the 4.0 release? Users will have to bounce up to the newer patch release with this flag in it anyway so they *could* set this flag as part of that upgrade process if they were bumping up to just get this functionality pre-upgrade. At least in my experience rolling restarts aren't a huge ordeal.
It seems like the real thorny part about all this is the introduction of the dynamic functionality back to 4.0 as it's a pretty straightforward deprecation path and UX for 5.1+ (i.e. deprecate old feature + add new guardrail + add JMX -> guardrail). On Wed, Nov 20, 2024, at 4:48 AM, Štefan Miklošovič wrote: > Hello, > > I am having a little bit of a hard time delivering (1). Long story short, > this was aimed to be added to 5.0 but we postponed it because it was too late > so the new target is 5.1. > > What we planned to do is to (2) deprecate alter_table_enabled in 5.0.1 which > is superseded by CASSANDRA-19556, then to introduce a system property to > avoid schema modifications in 4.0, 4.1 and 5.0 branches and eventually > replace alter_table_enabled by CASSANDRA-19556 which deals with this more > robustly. > > The problem we seem to hit is that "system property" in 4.0 -> 5.0 is not > enough, because if you think about that, system property has to be set when > nodes start. So when operators want to prevent schema modification, they have > to turn off a node, set the property and turn it back on. This is not optimal > and we were thinking that introducing _something dynamic_ which can be set in > runtime would be preferable, but we seem to hit a dead-end (3) because I am > not sure what path to choose here and people have become unresponsive since. > > From my point of view, the most ideal outcome would be to introduce an mbean > method to e.g. StorageService which sets a flag whether schema modifications > are possible or not, we would ship this to 4.0 -> trunk. Then in 5.0 we would > deprecate alter_table_enabled, in trunk we would remove alter_table_enabled > and introduced CASSANDRA-19556 and finally, in trunk, the introduced MBean > method on StorageService would internally translate to calling respective > guardrails we just introduced (4) so we do not need to deprecate it yet again. > > Does this make sense to people? My biggest concern is about introducing MBean > method to StorageService for lower branches as that technically counts as a > new feature but I think that if we want to have this dynamically settable / > in runtime, there is no way around that. > > I am all ears about doing this differently if you think what I propose here > is just too much and might be done in an alternative way. > > (1) https://issues.apache.org/jira/browse/CASSANDRA-19556 > (2) > https://issues.apache.org/jira/browse/CASSANDRA-19556?focusedCommentId=17848709&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17848709 > (3) > https://issues.apache.org/jira/browse/CASSANDRA-19828?focusedCommentId=17880018&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17880018 > (4) https://github.com/apache/cassandra/pull/3275 > > Regards
