OK, thanks all, we will go with 2), we will deprecate it in 5.0 and we remove it the next major.
________________________________________ From: Jeff Jirsa <jji...@gmail.com> Sent: Monday, July 10, 2023 18:13 To: dev@cassandra.apache.org Subject: Re: Removal of CloudstackSnitch NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. +1 On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie <jmcken...@apache.org<mailto:jmcken...@apache.org>> wrote: 2) keep it there in 5.0 but mark it @Deprecated I'd say Deprecate, log warnings that it's not supported nor maintained and people to use it at their own risk, and that it's going to be removed. That is, assuming the maintenance burden of it isn't high. I assume not since, as Brandon said, they're quite pluggable and well modularized. On Mon, Jul 10, 2023, at 9:57 AM, Brandon Williams wrote: I agree with Ekaterina, but also want to point out that snitches are pluggable, so whatever we do should be pretty safe. If someone discovers after the removal that they need it, they can just plug it back in. Kind Regards, Brandon On Mon, Jul 10, 2023 at 8:54 AM Ekaterina Dimitrova <e.dimitr...@gmail.com<mailto:e.dimitr...@gmail.com>> wrote: > > Hi Stefan, > > I think we should follow our deprecation rules and deprecate it in 5.0, > potentially remove in 6.0. (Deprecate in one major, remove in the next major) > Maybe the deprecation can come with a note on your findings for the users, > just in case someone somewhere uses it and did not follow the user mailing > list? > > Thank you > Ekaterina > > On Mon, 10 Jul 2023 at 9:47, Miklosovic, Stefan > <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote: >> >> Hi list, >> >> I want to ask about the future of CloudstackSnitch. >> >> This snitch was added 9 years ago (1). I contacted the original author of >> that snitch, Pierre-Yves Ritschard, who is currently CEO of a company he >> coded that snitch for. >> >> In a nutshell, Pierre answered that he does not think this snitch is >> relevant anymore and the company is using different way how to fetch >> metadata from a node, rendering CloudstackSnitch, as is, irrelevant for them. >> >> I also wrote an email to user ML list (2) about two weeks ago and nobody >> answered that they are using it either. >> >> The current implementation is using this approach (3) but I think that it is >> already obsolete in the snitch because snitch is adding a path to parsed >> metadata service IP which is probably not there at all in the default >> implementation of Cloudstack data server. >> >> What also bothers me is that we, as a community, seem to not be able to test >> the functionality of this snitch as I do not know anybody with a Cloudstack >> deployment who would be able to test this reliably. >> >> For completeness, in (1), Brandon expressed his opinion that unless users >> come forward for this snitch, he thinks the retiring it is the best option. >> >> For all cloud-based snitches, we did the refactorization of the code in >> 16555 an we work on improvement in 18438 which introduces a generic way how >> metadata services are called and plugging in custom logic or reusing a >> default implementation of a cloud connector is very easy, further making >> this snitch less relevant. >> >> This being said, should we: >> >> 1) remove it in 5.0 >> 2) keep it there in 5.0 but mark it @Deprecated >> 3) keep it there >> >> Regards >> >> (1) >> https://issues.apache.org/jira/browse/CASSANDRA-7147<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-7147&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7C5b174e223a4642a9970a08db8160b1ba%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638246024527024745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pKvx%2FCrDyfDEgcp7cbzL0xFJoyJ%2BMc%2BhFP1S%2BCkA2PM%3D&reserved=0> >> (2) >> https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fk4woljlk23m2oylvrbnod6wocno2dlm3&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7C5b174e223a4642a9970a08db8160b1ba%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638246024527024745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ULTydGDtfzeDg2dyBiifY37Edb8I0ujCffmr0%2BLwP%2F8%3D&reserved=0> >> (3) >> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.cloudstack.apache.org%2Fen%2Flatest%2Fadminguide%2Fvirtual_machines%2Fuser-data.html%23determining-the-virtual-router-address-without-dns&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7C5b174e223a4642a9970a08db8160b1ba%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638246024527180994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nNFugtAM2H1k%2FuTqcjOtZePmxCidR7eKaAvy%2BG33zn4%3D&reserved=0>
