[
https://issues.apache.org/jira/browse/CASSANDRA-19488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906496#comment-17906496
]
Stefan Miklosovic edited comment on CASSANDRA-19488 at 12/17/24 6:30 PM:
-------------------------------------------------------------------------
while eleven is better than five hundred+, it still failed some tests which I
believe are somehow related to the combination with _latest yaml, like
replication_test.TestSnitchConfigurationUpdate
snitch_test.TestGossipingPropertyFileSnitch
nodetool_test.TestNodetool.test_correct_dc_rack_in_nodetool_info
rebuild_test.TestRebuild.test_resumable_rebuild seems suspicious as well if you
check the error message
not sure about the rest
3x rebuild_test.TestRebuild
https://app.circleci.com/pipelines/github/instaclustr/cassandra/5139/workflows/d2fdc1ca-213f-4c3f-9b95-26737f50feef/jobs/314388/tests
thanks [~marcuse]
was (Author: smiklosovic):
while ten is better than five hundred+, it still failed some tests which I
believe are somehow related to the combination with _latest yaml, like
replication_test.TestSnitchConfigurationUpdate
snitch_test.TestGossipingPropertyFileSnitch
nodetool_test.TestNodetool.test_correct_dc_rack_in_nodetool_info
rebuild_test.TestRebuild.test_resumable_rebuild seems suspicious as well if you
check the error message
not sure about the rest
3x rebuild_test.TestRebuild
https://app.circleci.com/pipelines/github/instaclustr/cassandra/5139/workflows/d2fdc1ca-213f-4c3f-9b95-26737f50feef/jobs/314388/tests
thanks [~marcuse]
> Ensure snitches always defer to ClusterMetadata
> -----------------------------------------------
>
> Key: CASSANDRA-19488
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19488
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Cluster/Membership, Messaging/Internode, Transactional
> Cluster Metadata
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Internally, C* always uses {{ClusterMetadata}} as the source of topology
> information when calculating data placements, replica plans etc and as such
> the role of the snitch has been somewhat reduced.
> Sorting and comparison functions as provided by specialisations like
> {{DynamicEndpointSnitch}} are still used, but the snitch should only be
> responsible for providing the DC and rack for a new node when it first joins
> a cluster.
> Aside from initial startup and registration, snitch implementations should
> always defer to {{{}ClusterMetadata{}}}, for DC and rack otherwise there is a
> risk that the snitch config drifts out of sync with TCM and output from tools
> like {{nodetool ring}} and {{gossipinfo}} becomes incorrect.
> A complication is that topology is used when opening connections to peers as
> certain internode connection settings are variable at the DC level, so at the
> time of connecting we want to check the location of the remote peer. Usually,
> this is available from {{{}ClusterMetadata{}}}, but in the case of a brand
> new node joining the cluster nothing is known a priori. The current
> implementation assumes that the snitch will know the location of the new node
> ahead of time, but in practice this is often not the case (though with
> variants of {{PropertyFileSnitch}} it _should_ be), and the remote node is
> temporarily assigned a default DC. This is problematic as it can cause the
> internode connection settings which depend on DC to be incorrectly set.
> Internode connections are long lived and any established while the DC is
> unknown (potentially with incorrect config) will persist indefinitely. This
> particular issue is not directly related to TCM and is present in earlier
> versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
