Happy to leave the dynamic setting of this in runtime out and go with a good old system property in each patch release from 4.0.x to 5.0.x if it is enough for people. We would deprecate alter_table_enabled in 5.0.x and remove it in trunk with the introduction of CASSANDRA-19556.
What do you think should happen with this newly-introduced system property in trunk? Removing it mercilessly in the trunk without any deprecation? On Wed, Nov 20, 2024 at 12:57 PM Josh McKenzie <jmcken...@apache.org> wrote: > 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 > > >
