Hi All , I tested the AlibabaCloudSnitch、 AlibabaCloudLocationProvider together with NetworkTopologyProximity/NoOpProximity under Alibaba cloud's environment, region : c-hangzhou-b. I builded the package using Sam's final PR and deployed three Cassandra nodes, my test cases are : 1、node joing/decommission; 2、create keyspace and table then doing some insert and select; 3、nodetool ring/status/cms； All results are correct, the dc is c-hangzhou, rack is : b Thanks Sam !
guo Maxwell <cclive1...@gmail.com> 于2024年12月12日周四 21:47写道： > Hi sam > I can help with the validation of AlibabaCloudSnith. > > Sam Tunnicliffe <s...@beobal.com>于2024年12月12日 周四下午9:20写道： > >> This patch is probably now ready to merge, having been through several >> iterations of review and with green CI. Before that though, I just want to >> send one more reminder about it. We've endeavoured to preserve all existing >> behaviour and to keep configuration 100% backwards compatible. However, >> some areas have had minimal testing in real clusters, specifically the >> various cloud platform configurations: >> >> * Ec2Snitch/Ec2MultiRegionSnitch >> * AzureSnitch >> * AlibabaCloudSnitch >> * GoogleCloudSnitch >> * CloudstackSnitch >> >> Any help in validating these in their native environments would be >> welcome. >> >> The other consideration is toward custom snitch implementations. The >> intention is that these should continue to work without interruption or >> intervention, unless they're leaning heavily on C* internals in which case >> any changes required ought to be minimal. So it would be great if anyone >> using a custom snitch implementation is able to check it out and help >> verify that. >> >> >> > On 31 Oct 2024, at 16:53, Sam Tunnicliffe <s...@beobal.com> wrote: >> > >> > Since CEP-21, the source of truth for topology info (a node's >> datacenter & rack) is ClusterMetadata. Each node provides its dc/rack when >> it registers itself with the cluster prior to joining and this information >> is effectively immutable (for now). This significantly reduces the scope of >> IEndpointSnitch's responsibilities and CASSANDRA-19488 proposes a >> refactoring which breaks out the remaining functionality into a handful of >> new providers (full details can be found in the JIRA). >> > >> > This is one of the more widely used extension points in Cassandra, so >> we wanted to bring it to the mailing list in addition to discussing on >> JIRA. >> > >> > To be clear, no operator intervention should be necessary when >> upgrading. To ease migration onto the new config and to allow us to >> deprecate snitches in a controlled way, it will remain fully supported to >> configure nodes using the endpoint_snitch setting in yaml. A SnitchAdapter >> acts as a facade in this case, presenting the new interfaces to calling >> code while delegating to the legacy snitch. Most of the in-tree snitches >> have been refactored to extract implementations of the new interfaces so >> that their functionality can be used via the new configuration. >> > >> > Some questions for the list: >> > >> > * We have added 2 new methods to IEndpointSnitch, which have >> essentially been pulled up from Ec2MultiRegionSnitch and >> GossipingPropertyFileSnitch to support ReconnectableSnitchHelper. >> Currently, these are added as default methods on the interface so that >> out-of-tree snitches remain binary compatible. However, it would be safer >> to break binary compatibility in this case to ensure that any custom >> snitches out in the wild must be updated and their behaviour is preserved. >> So the question is, would there be objections to extending the (now >> deprecated) IEndpointSnitch interface in this way? >> > >> > * Python dtests and config are currently unchanged (aside from some >> error message checks) so these are exercising the path whereby the clusters >> are configured with endpoint_snitch and make use of the compatibility >> adapter. In-jvm upgrade dtests switch from old to new style configuration >> on upgrade to 5.1 (though in truth, these don't exercise snitches much at >> all as a special dtest snitch is used throughout). cassandra-latest.yaml >> contains the new settings, while cassandra.yaml and the variations in >> test/conf retain the old style settings. How should we approach updating >> these configs so that we maintain a balance between test coverage, >> compatibility during upgrades and encouraging the use of new style config >> in fresh clusters? >> > >> >>
