[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145105#comment-16145105 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- The reason it isn't listed is because we want to allow changing the replication strategy/factor on those keyspaces themselves. It's just that it's been implemented sub-diligently. So we want reject any changes to the tables (including dropping them), reject dropping of those keyspaces, but allow altering keyspace params. Also reject: creating of new tables in those keyspaces. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145207#comment-16145207 ] Sylvain Lebresne commented on CASSANDRA-13813: -- bq. The reason it isn't listed is because we want to allow changing the replication strategy/factor on those keyspaces themselves. The name of the set makes it clear what the _intention_ was. What I'm saying is that the code doesn't implement that intention. Currently, you can alter the replication strategy/factor of _all_ system distributed keyspace, even {{system_distributed}}, and I'm reasonably convinced that wasn't the intention. This certainly isn't hard to fix though. Now with that said, I happen to not particularly see a terribly good reason to limit which of the system distributed keyspace can have their strategy/factor changed (and again, despite the original code intention, we currently _don't_ have such limit), so instead of simply making the check on {{ALTERABLE_SYSTEM_KEYSPACES}} work as originally intended (and thus starting to forbid changing the RF on {{system_distributed}}), I'd advocate for just removing {{ALTERABLE_SYSTEM_KEYSPACES}} and deal with all those keyspace consistently. Just my 2 cents though. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145227#comment-16145227 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- Not having {{system_distributed}} in {{ALTERABLE_SYSTEM_KEYSPACES}} is an oversight from the patch that added {{system_distributed}}. Had it been added correctly, CASSANDRA-13812 would not be a problem - {{ClientState.preventSystemKSSchemaModification()}} would've forbidden those drops. The constant is there to enumerate the keyspace whose tables cannot be modified, and that's the purpose it serves. It might not have the best possible name, though, or be ideally documented. I'd start with adding {{system_distributed}} to {{ALTERABLE_SYSTEM_KEYSPACES}} - that would immediately fix CASSANDRA-13812 and this ticket. Then rename {{ALTERABLE_SYSTEM_KEYSPACES}} to something more descriptive (even {{PARTIALLY_ALTERABLE_SYSTEM_KEYSPACES}} would be a start. And document the intent. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug >Reporter: Sylvain Lebresne > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193296#comment-16193296 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- Fixes for [3.0|https://github.com/iamaleksey/cassandra/tree/13813-3.0], [3.11|https://github.com/iamaleksey/cassandra/tree/13813-3.11], [4.0|https://github.com/iamaleksey/cassandra/tree/13813-4.0] and a new [dtest|https://github.com/iamaleksey/cassandra-dtest/tree/13813]. Utests and dtests queued up. [~slebresne] Any chance you could review? I've implemented what we talked about on IRC - and renamed some confusingly named things while at it. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194441#comment-16194441 ] Sylvain Lebresne commented on CASSANDRA-13813: -- So the thing is that due to how the existing code is work, we currently allow anything on the tables of the {{system_distributed}} tables. And while I doubt there is any debate that we shouldn't let use drop those tables, or even drop/rename columns of those tables, some user may have been relying on altering these table _properties_. CASSANDRA-12701 particularly comes to mind here: it's kind of a bug that the repair tables in there don't have TTLs and so user may have legitimately work around it by adding the table TTL themselves. The attached patch will remove the ability for this work-around (to be extra precise, user that have already changed the properties would obviously be fine, it's new user wanting to do it that wouldn't be able to), and this feels uncomfortable to do in minor releases at least. I guess, if we make sure to commit CASSANDRA-12701 before this, we at least remove one imo legitimate reason to modify those tables params and that would be better. Even without that though, modifying some system tables params isn't an entirely crazy idea (we can debate whether that's truly useful, but it's not crazy) and this remove that ability. Don't get me wrong btw, I know that we currently only allow this for {{system_distributed}} tables and so it's inconsistent with other system keyspace in the first place, and I'm not definitively saying we should allow modifying params on all system tables. I'm just raising the point that the patch removes something that could be considered as useful by some, and doing so in a minor concerns me a little bit. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194557#comment-16194557 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- [~slebresne] I don't believe it's reasonable to keep bugs in the codebase just because they mask out other bugs. Leaving this ability is dangerous, as it breaks the assumptions we make about replicated system keyspaces, and the way we alter them. Those who make these changes manually - because we weren't careful enough and haven't shielded them from being able to - might have to pay the price later, when their cluster are unable to pick up our altered defaults, because of our bumped hardcoded timestamps being smaller than the new ones set via {{ALTER TABLE}}. FWIW, those who are really keen to work around this issue, might as well alter {{system_schema.tables}} manually, and get the desired result. With just as much risk. Either way, again, I don't believe that keeping the bug in just because it masks the bug in CASSANDRA-12701 is reasonable. So if you are only slightly concerned and don't mind really strongly, I'd prefer to go ahead and fix this issue here and now, before more people shoot themselves in the feet. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194621#comment-16194621 ] Sylvain Lebresne commented on CASSANDRA-13813: -- bq. I don't believe it's reasonable to keep bugs in the codebase just because they mask out other bugs. Just to make sure my position is clear, I'm not suggesting we leave this ticket unsolved. What I'm suggesting is that it would be possible to forbid truly harmful changes (droping tables and adding/removing/renaming columns; that part is the real bug to me) while still allowing the altering of table parameters (which actually don't seem that problematic to me on principle). Sure, it requires adding some special casing in {{AlterTableStatement}}, but it's not very complex either. bq. when their cluster are unable to pick up our altered defaults, because of our bumped hardcoded timestamps being smaller than the new ones set via ALTER TABLE I'm not sure I understand the problem. If user have manually and knowingly updated some table params, my guess is that they expect (even rely on) future changes to defaults to not override their changes. Isn't the whole point why we've picked 0 for our hardcoded timestamp in fact? But if there is genunine reason I'm missing that make it dangerous for user to alter those parameters, that's certainly important to understand. I'm pretty sure some user _have_ done it (at least to work around CASSANDRA-12701, possibly for other reasons), and if their change is a time-bomb, we kind of owe them to disarm that bomb. But anyway, to sum it up, the patch lgtm from a technical level, and I'm definitively on board with forbidding clearly harmful changes. The only specific part I'm unsure is the "altering table parameters" part. In light of my current understanding, it doesn't look obviously harmful (I can even see it being desirable if I'm being honest), so I'm uncomfortable removing the ability in a minor release. Happy to gather a few other opinions though and if the concensus is that the patch is fine the way it currently is, no problem, not trying to veto this in any way. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196789#comment-16196789 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- bq. I'm not sure I understand the problem. If user have manually and knowingly updated some table params, my guess is that they expect (even rely on) future changes to defaults to not override their changes. Isn't the whole point why we've picked 0 for our hardcoded timestamp in fact? Right. But the way ALTER works, we serialise the whole table, including all params and all columns, with the new timestamp in {{system_schema.*}} tables. Which makes it impossible for us to change the defaults later, even those that the user didn't modify on purpose. And this isn't something we can change very easily in a minor I'm afraid. This is why we don't allow altering anything beyond keyspace params, and why this issue is, as it stands, a serious bug, and was never intended to be allowed. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196803#comment-16196803 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- FWIW, I'll be the first to admit that the current situation is not ideal. It wasn't me who came up with it, but I share part of the blame - replicated system keyspaces are a bit of a mess, and this has already caused us some issues, and hassle with {{system_auth}}, and it won't be the last. We can't even fix CASSANDRA-12701 properly in a minor without causing migration mismatch fun. So all things considered, my personal preference would be to shield existing users from causing further issues for themselves by accidentally or intentionally modifying those tables. At least until we have a good answer to these related issues, which I don't :( > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196920#comment-16196920 ] Sylvain Lebresne commented on CASSANDRA-13813: -- bq. But the way ALTER works, we serialise the whole table, including all params and all columns Good point, I hadn't though about that part. Sad! So I guess I would agree in principle about shielding user against clearly dysfunctional behaviors. The problem is that in practice I know for a fact that CASSANDRA-12701 has been an issue for some users, where the tables had been growing way too much, to the point that being able to work-around that by setting a TTL manually probably override concerns about hypothetical future changes to defaults not being picked up. Or to put it another way, none of this is ideal, but I wonder is "repair history tables regularly grows out of control regularly" isn't a bigger problem in practice than "future defaults changes to system tables may not be picked up". Anyway, again, not opposed on the current patch personally, but uneased by it, so wouldn't mind a few additional opinion to see if it's just me being difficult (which is possible). > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16196923#comment-16196923 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- bq. so wouldn't mind a few additional opinion to see if it's just me being difficult (which is possible). Oh, you've never been difficult. Neither have I. FWIW I don't feel very strongly about this going to 3.0.x vs. this going to 4.0 only. Worst case I'll just fix this for us internally. Seeing that neither of us feels really strongly about this, I don't mind getting some opinions from others, either. I'll throw a signal on IRC and hopefully someone will reply. Either way it's not urgent. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197002#comment-16197002 ] Jeremiah Jordan commented on CASSANDRA-13813: - I am a little concerned about this change not letting anything be updated, but I do understand the reasons, and I can't really see a way around them. Given that an experience person can still get around this restriction by doing inserts into the schema tables, that is probably enough if there are any future bugs to be worked around. Un-experienced users should not be changing these values by themselves. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16197996#comment-16197996 ] Kurt Greaves commented on CASSANDRA-13813: -- I think if we can't provide a data model for our tables that works for all scenarios then we need to allow operators to make changes. I've had quite a few occasions where modifying "system" tables was necessary, and I'm sure more tables will be introduced that don't work in all scenarios in the future. While there is the workaround of just inserting into the system_schema tables that is fraught with peril, and far more likely for them to do something that breaks things. I can't see someone saying "woops I accidentally DROPped/ALTERed a random column in system_distributed.view_build_status", but I can definitely see someone trying to insert into system_schema.tables and making mistakes. As soon as we make them replicated we hand over some responsibility to the operator to manage them (not that the non-replicated keyspaces have a history of being perfect though), and I'd expect to be able to change table properties that potentially affect the cluster. Cassandra already requires you to know what your doing as an operator, this really doesn't increase that expectation. There are a million other bad choices you could make when managing a cluster that would be far more catastrophic (and far more likely). I would like to move away from that, but a lot of that sort of thing requires major changes to fix. As in this case it seems we'll need the capability limitation framework or other major changes to make a reasonable compromise. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198456#comment-16198456 ] Sylvain Lebresne commented on CASSANDRA-13813: -- bq. an experience person can still get around this restriction by doing inserts into the schema tables I also just realized that doing so actually avoids the issue we currently have with {{ALTER}} that it rewrites all columns, so it makes it a somewhat better work-around (of course, still a work-around and that don't dispense us for fixing all this more cleanly). My only bother is that while I haven't actually tried it recently, last time I did try updating the schema tables manually, it was annoying because the changes were not automatically picked-up and in fact tended to be overridden, so I had to force a reload in weird ways (altering some other unrelated table in the keyspace, which here would actually be an issue). So it would be nice if we added a JMX call to force reload schema tables from disk to make this easier (should be easy). If we do, I'm warming up to the idea of considering this is the only really safe work-around until we find a better way to deal with all thise. bq. if we can't provide a data model for our tables that works for all scenarios then we need to allow operators to make changes. I'm not sure what you are trying to mean by that. If it's a reference to CASSANDRA-12701, then what makes that change problematic is the very same reason why leaving {{ALTER}} working here is problematic. So feel free to suggest a concrete solution to those problems if you have one, but otherwise, I'm not sure how this statement helps make a decision on this issue. bq. I've had quite a few occasions where modifying "system" tables was necessary, and I'm sure more tables will be introduced that don't work in all scenarios in the future. First, it would be nice if you could be a bit more concrete on those time where it was "necessary": which tables, what modification and why what it necessary? We're trying to find the best course of action for a very concrete problem and we are all experienced C* developers: let's be specific. Second, I'm not sure how to re-conciliate that sentence as a whole to the concrete problem at end. Let's remind that we do _already_ refuse {{ALTER}} on most system tables, and this ticket is not about discussing whether we should allow {{ALTER}} on system tables _in general_. If you want to discuss that, I'm good with it (outside of the fact that we will have to solve the technical gotcha mentioned above) and your arguments seem to really be applied to such change, but please open a separate ticket and let's not divert that one. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198482#comment-16198482 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- bq. My only bother is that while I haven't actually tried it recently, last time I did try updating the schema tables manually, it was annoying because the changes were not automatically picked-up and in fact tended to be overridden, so I had to force a reload in weird ways (altering some other unrelated table in the keyspace, which here would actually be an issue). So it would be nice if we added a JMX call to force reload schema tables from disk to make this easier (should be easy). If we do, I'm warming up to the idea of considering this is the only really safe work-around until we find a better way to deal with all thise. Yep. You either do an unrelated {{ALTER}} (usually {{WITH comment = ...}}) or bounce the node. Also wouldn't mind at all adding the new JMX call, as a companion to {{resetlocalschema}}. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198490#comment-16198490 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- [~slebresne] I can/will extend the patch with a new {{reloadlocalschema}} JMX call and a nodetool cmd when/if you warm up to it sufficiently (: > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203638#comment-16203638 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- Created CASSANDRA-13954 for jmx/nodetool work. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205377#comment-16205377 ] Kurt Greaves commented on CASSANDRA-13813: -- bq. I'm not sure what you are trying to mean by that. Not sure how to make this clearer. If we can't provide a one-size-fits-all solution for our system distributed tables, which we can't, we should allow for them to be modified by operators. In CASSANDRA-12701 we can't set a TTL because we can't pick a TTL that's appropriate for all use cases (or compaction strategy for that matter). Users have to pick their own, thus we should allow them to change these properties. So far it only may be that TTL is the one that users need to change, but I'm sure there are potentially others, and I'm sure there will be more in the future. bq. First, it would be nice if you could be a bit more concrete on those time where it was "necessary" Sure, I've had to change TTL as per CASSANDRA-12701 multiple times. I've never bothered changing compaction strategy but obviously that would be beneficial. I've also had to set up jobs to routinely truncate system_traces. This may sound absurd, but in environments where you don't necessarily have control over clients, it is applicable. Being able to TTL on this keyspace would improve things here. I've also had to drop tables in system_distributed on occasion when for some reason or another they got corrupt/different ID's across the cluster. This has also occured for system_traces, but obviously had to delete manually from system_schema. Obviously also the usual system_auth changes, however so far that only relates to modifying RF, but I'll note that we do require dropping tables in that keyspace for conversion to role based access. bq. this ticket is not about discussing whether we should allow ALTER on system tables in general. Yep, I was never talking about system tables in general, just the distributed ones. I thought this would be obvious considering that's what the ticket was about. I think it's worth pointing out the following as well, because it's been raised that having alterable system_distributed tables is a major defect. This issue (and related ones) were raised by developers as "major" issues. There appears to be no evidence so far that this issue has actually affected users. We're rushing to fix it because for some reason, all of a sudden, we've determined that users breaking their own cluster by doing funny things is a huge problem. This is odd to me, considering users routinely break their clusters by running repairs, but I've never heard of anyone breaking their cluster because they altered a system "distributed" keyspace. There appears to be no evidence that you can really do catastrophic damage by altering these tables. If we fixed the fact that they don't get recreated automatically anymore I'm pretty sure any issues created by doing odd changes on the tables (which is very unlikely) would easily be resolved by dropping the tables and restarting a node. On that note, not sure if repair actually will break if the history tables are broken, but as far as MV are concerned, they keep working even if you truncate/drop the tables. The suggested fix still leaves a workaround to make the changes we'd be blocking here, and this is on purpose. This kind of implies that we're perfectly OK with users making these changes. I mean, if this is an actual issue surely we should also create a ticket "Don't let user insert garbage into system_schema". I'm really not convinced that this is such a major high priority issue that we can't just put it off until 4 and fix it with something more reasonable like the capability limitation framework, while maintaining the current behaviour. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207161#comment-16207161 ] Sylvain Lebresne commented on CASSANDRA-13813: -- As suggested earlier, I'm personally +1 on the patch here now that we have CASSANDRA-13954. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.x, 3.11.x > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13813) Don't let user drop (or generally break) tables in system_distributed
[ https://issues.apache.org/jira/browse/CASSANDRA-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207589#comment-16207589 ] Aleksey Yeschenko commented on CASSANDRA-13813: --- Thanks. Committed to 3.0 as [9e37967e17a1b223df35c1c7cec4dc4adf0b2d91|https://github.com/apache/cassandra/commit/9e37967e17a1b223df35c1c7cec4dc4adf0b2d91] and merged up with 3.11 and trunk. Dtest committed as [957ae2bc455c56835632193e1aa251495c3724f8|https://github.com/apache/cassandra-dtest/commit/957ae2bc455c56835632193e1aa251495c3724f8]. > Don't let user drop (or generally break) tables in system_distributed > - > > Key: CASSANDRA-13813 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13813 > Project: Cassandra > Issue Type: Bug > Components: Distributed Metadata >Reporter: Sylvain Lebresne >Assignee: Aleksey Yeschenko > Fix For: 3.0.16, 3.11.2 > > > There is not currently no particular restrictions on schema modifications to > tables of the {{system_distributed}} keyspace. This does mean you can drop > those tables, or even alter them in wrong ways like dropping or renaming > columns. All of which is guaranteed to break stuffs (that is, repair if you > mess up with on of it's table, or MVs if you mess up with > {{view_build_status}}). > I'm pretty sure this was never intended and is an oversight of the condition > on {{ALTERABLE_SYSTEM_KEYSPACES}} in > [ClientState|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ClientState.java#L397]. > That condition is such that any keyspace not listed in > {{ALTERABLE_SYSTEM_KEYSPACES}} (which happens to be the case for > {{system_distributed}}) has no specific restrictions whatsoever, while given > the naming it's fair to assume the intention that exactly the opposite. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org