[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=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
[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=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=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.java#L397].
>
[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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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=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
