Re: Removal of CloudstackSnitch
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 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 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 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 > 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#deter
Re: Removal of CloudstackSnitch
+1 On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie 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 > 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> 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 > >> (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3 > >> (3) > https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns > > >
Re: Removal of CloudstackSnitch
> 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 > 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 > > 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 > >> (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3 > >> (3) > >> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns >
Re: Removal of CloudstackSnitch
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 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 > 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 >> (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3 >> (3) >> https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns
Re: Removal of CloudstackSnitch
Hey, should we still keep it around if we are not even sure it still works? As I see it, we are not able to verify it works on 5.0 release. What value there is in a snitch we do not know is still functioning? Regards From: Ekaterina Dimitrova Sent: Monday, July 10, 2023 15:54 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. 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 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%7Cd3e27fac4ba3422e1a9d08db814d32d7%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638245940784302755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4TbU6OYhFyPh2qI5gt7u29xP%2BeWM8n%2B%2FmEp4iUnvnUw%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%7Cd3e27fac4ba3422e1a9d08db814d32d7%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638245940784302755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JqpMHE8pAedxA6ulx5I3uNMGI9zwMHxeOUCZCGZ36kk%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%7Cd3e27fac4ba3422e1a9d08db814d32d7%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638245940784302755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2BsSpNkcqbKJyBe%2BVFapeAbFuFttQWMqwKH%2FRyef4xg%3D&reserved=0>
Re: Removal of CloudstackSnitch
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> 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 > (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3 > (3) > https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns
Removal of CloudstackSnitch
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 (2) https://lists.apache.org/thread/k4woljlk23m2oylvrbnod6wocno2dlm3 (3) https://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html#determining-the-virtual-router-address-without-dns
