We should remove CloudstackSnitch in the next major (1). It is already deprecated.
I will try to test Azure tomorrow, don't have capacity / time to test anything else for now but we will definitely make sure we test it all before we release. (1) https://lists.apache.org/thread/2zxvbjoynhvsr33cc9h9xv99sdvjldn8 On Thu, Dec 12, 2024 at 2:20 PM Sam Tunnicliffe <s...@beobal.com> wrote: > 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? > > > >
