[
https://issues.apache.org/jira/browse/CASSANDRA-13041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728772#comment-17728772
]
Stefan Miklosovic edited comment on CASSANDRA-13041 at 6/2/23 2:51 PM:
-----------------------------------------------------------------------
Nevertheless, I implemented guardrail approach here (1).
What I do not like about the current implementation is that it is wired into
NetworkTopologyStrategy. While this "just works" because system_auth is
basically on NTS _all the time_, I feel like this kind of stuff should not be
wired in NTS only.
There might be different replication strategies, in theory, and having this
wired in NTS will make other strategies necessary to replicate this logic?
Also, what if there are keyspaces in the future which need to have same
treatment?
So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now
it is replication-strategy-agnostic.
If we take more generic approach to the introduced guardrail, it should be
probably renamed to not contain "system_auth" string.
Something like "system_keyspace_dc_removal_protection" would be more
appropriate? We would then just added more keyspaces if they happen to suffer
from the same problem system_auth was.
I still think this makes sense to rework. Guardrails would make it able to
override and emit warning only if really needed for power users and it would be
by default disabled as already existing solution did it.
cc [~jmckenzie] [~brandon.williams]
(1) https://github.com/apache/cassandra/pull/2384
was (Author: smiklosovic):
Nevertheless, I implemented guardrail approach here (1).
What I do not like about the current implementation is that it is wired into
NetworkTopologyStrategy. While this "just works" because system_auth is
basically on NTS _all the time_, I feel like this kind of stuff should not be
wired in NTS only.
There might be different replication strategies, in theory, and having this
wired in NTS will make other strategies necessary to replicate this logic?
Also, what if there are keyspaces in the future which need to have same
treatment?
So, I implemented it in AlterKeyspaceStatement and removed it from NTS and now
it is replication-strategy-agnostic.
I still think this makes sense to rework. Guardrails would make it able to
override and emit warning only if really needed for power users and it would be
by default disabled as already existing solution did it.
cc [~jmckenzie] [~brandon.williams]
(1) https://github.com/apache/cassandra/pull/2384
> Do not allow removal of a DC from system_auth replication settings if the DC
> has active Cassandra instances
> -----------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-13041
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13041
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Distributed Metadata
> Reporter: Nachiket Patil
> Assignee: Stefan Miklosovic
> Priority: Low
> Fix For: 5.x
>
> Attachments: trunk.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I don’t believe it is ever correct to remove a DC from the system_auth
> replication settings while there are nodes up in that DC. Cassandra should
> not allow this change if there are hosts which are currently members of the
> cluster in that DC, as any request which is routed to these hosts will meet
> an unavailable. Also dropping the keyspace system_auth should not be allowed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
