You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alexander Murmann <am...@vmware.com> on 2022/04/15 00:15:41 UTC
[discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://ben.balter.com/2016/07/21/removing-a-feature-is-a-feature/>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Dan Smith <da...@vmware.com>.
The PRs to remove this module have been approved merged - from geode, geode-benchmarks, and geode-examples.
-Dan
________________________________
From: Dan Smith <da...@vmware.com>
Sent: Wednesday, May 4, 2022 2:06 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
Since it seems there is consensus to remove this module, I created this PR - https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7657&data=05%7C01%7Cdasmith%40vmware.com%7C14930b4554a64bb27a5f08da2e12028a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872952170457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l0rohEOfWZASMGmsiq8NCvB%2F1aIN3NbAM45aQdcHS6k%3D&reserved=0. If folks approve of this PR there will be additional PRs to geode-benchmarks and geode-examples to remove references to this module.
-Dan
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Wednesday, May 4, 2022 11:04 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
Hi Donal,
I think Dan, Ray or Jens were going to issue a PR in the next few days that would remove the experimental Redis functionality. Given this is not a complex architectural change that might warrant deeper discussion, I would expect that the voting inherent to the PR would suffice. Especially, given that the discussion here seemed very non-controversial.
________________________________
From: Donal Evans <do...@vmware.com>
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
It's been almost a month since this discussion was started, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action?
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Cdasmith%40vmware.com%7C14930b4554a64bb27a5f08da2e12028a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872952170457035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Muoq%2FVBILzuQVebwnbjhuHW3TGXwQAXBoylBzm0UfCA%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Dan Smith <da...@vmware.com>.
Since it seems there is consensus to remove this module, I created this PR - https://github.com/apache/geode/pull/7657. If folks approve of this PR there will be additional PRs to geode-benchmarks and geode-examples to remove references to this module.
-Dan
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Wednesday, May 4, 2022 11:04 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
Hi Donal,
I think Dan, Ray or Jens were going to issue a PR in the next few days that would remove the experimental Redis functionality. Given this is not a complex architectural change that might warrant deeper discussion, I would expect that the voting inherent to the PR would suffice. Especially, given that the discussion here seemed very non-controversial.
________________________________
From: Donal Evans <do...@vmware.com>
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
It's been almost a month since this discussion was started, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action?
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Cdasmith%40vmware.com%7C600bdec2f8d14fc583ca08da2df89027%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872842843468581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PQa24X3EQPh8J%2FVL1lvhGLVAT3wfzZEAm7I7g%2FlFK10%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Alexander Murmann <am...@vmware.com>.
Hi Donal,
I think Dan, Ray or Jens were going to issue a PR in the next few days that would remove the experimental Redis functionality. Given this is not a complex architectural change that might warrant deeper discussion, I would expect that the voting inherent to the PR would suffice. Especially, given that the discussion here seemed very non-controversial.
________________________________
From: Donal Evans <do...@vmware.com>
Sent: Wednesday, May 4, 2022 09:28
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
It's been almost a month since this discussion was started, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action?
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Camurmann%40vmware.com%7Ccc72fa6b54bf478a5ec708da2deb17de%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637872784991405843%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=fJjO4SpuCBeyTG1hFc%2FXR8vyBMIDbWK8p9jbtOZLnJo%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Donal Evans <do...@vmware.com>.
It's been almost a month since this discussion was started, and all the responses have been supportive of the idea. Is this still something that the Geode community intends to do? Should there be a [vote] email sent out to confirm this course of action?
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Cdoevans%40vmware.com%7C3d08029d93f8465add5408da1e751bbb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855785572189285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyE2Pj9QlqCtABg2%2BF0VCZ1RRHh5D%2Bm1STb%2B1fwtuAc%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Dave Barnes <db...@apache.org>.
I regularly contribute to the documentation, and I support this change.
Removal of the experimental Redis module would lighten the burden for those
who maintain the Geode documentation.
On Thu, Apr 14, 2022 at 10:39 PM Owen Nichols <on...@vmware.com> wrote:
> Well said, Donal.
>
> As a past Release Manager, geode-for-redis impacted release timelines for
> 1.13, 1.14, and most recently 1.15. I support this proposal in hopes that
> refocusing on core Geode makes future releases a little more predictable.
>
> Now might also be a good time to review other features in Geode that are
> marked @Experimental, such as manageability REST API, JDBC connector,
> micrometer, SSLParameterExtension, GfshCommand, or AutoBalancer. I hope
> this proposal encourages more proposals to either shelve or promote some of
> these other experiments.
>
> From: Donal Evans <do...@vmware.com>
> Date: Thursday, April 14, 2022 at 9:10 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [discuss] Future of the geode-redis module
> I agree with this proposal.
>
> As someone who has contributed a great deal of time and effort to the
> geode-for-redis module in the past year or so, it's sad to see it go, but
> realistically, the last thing that Geode needs is more unmaintained code.
> Our track record for removing dead or deprecated code is pretty poor, so
> removing this before it gets a chance to add to the burden seems like a
> sensible idea. In addition to this, the tests in the geode-for-redis module
> contribute significantly to the total run time of CI pipeline jobs,
> particularly the acceptance tests, in which geode-for-redis tests account
> for over 50% of the total run time.
> ________________________________
> From: Alexander Murmann <am...@vmware.com>
> Sent: Thursday, April 14, 2022 5:15 PM
> To: geode <de...@geode.apache.org>
> Subject: [discuss] Future of the geode-redis module
>
> Hi Geode community!
>
> A while ago engineers from VMware started to improve the geode-redis
> module that has been in Geode for several years, but never had been
> completed. This involved adding more tests for existing functionality, as
> well as adding support for more commands.
>
> VMware will not continue this investment in the geode-redis module. While
> the geode-redis module is in a much better place than two years ago there
> still is a lot of work left to make it a viable option for most of our
> users and the module is still in an experimental state.
>
> For the community this poses the question of what we want to do with the
> existing code. This work now has been started and stopped twice. All code
> comes with a maintenance burden which adds up<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Conichols%40vmware.com%7C446f816dd25e4b44826908da1e95e1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855926345514685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rherU8SIujYGLQXkXgIUPCBUtHvMaSy71FQkIvvSWjc%3D&reserved=0>.
> Dependencies might need to be updated; flaky tests fixed and it brings
> cognitive overhead for us and our users. Unless someone else in the
> community steps up to take on the task of maintaining the geode-redis
> module, I propose to remove the code from our develop branch and give
> everyone more bandwidth to use elsewhere.
>
> Thank you all in advance for your thoughts
>
Re: [discuss] Future of the geode-redis module
Posted by Owen Nichols <on...@vmware.com>.
Well said, Donal.
As a past Release Manager, geode-for-redis impacted release timelines for 1.13, 1.14, and most recently 1.15. I support this proposal in hopes that refocusing on core Geode makes future releases a little more predictable.
Now might also be a good time to review other features in Geode that are marked @Experimental, such as manageability REST API, JDBC connector, micrometer, SSLParameterExtension, GfshCommand, or AutoBalancer. I hope this proposal encourages more proposals to either shelve or promote some of these other experiments.
From: Donal Evans <do...@vmware.com>
Date: Thursday, April 14, 2022 at 9:10 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [discuss] Future of the geode-redis module
I agree with this proposal.
As someone who has contributed a great deal of time and effort to the geode-for-redis module in the past year or so, it's sad to see it go, but realistically, the last thing that Geode needs is more unmaintained code. Our track record for removing dead or deprecated code is pretty poor, so removing this before it gets a chance to add to the burden seems like a sensible idea. In addition to this, the tests in the geode-for-redis module contribute significantly to the total run time of CI pipeline jobs, particularly the acceptance tests, in which geode-for-redis tests account for over 50% of the total run time.
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Conichols%40vmware.com%7C446f816dd25e4b44826908da1e95e1f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855926345514685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rherU8SIujYGLQXkXgIUPCBUtHvMaSy71FQkIvvSWjc%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts
Re: [discuss] Future of the geode-redis module
Posted by Donal Evans <do...@vmware.com>.
I agree with this proposal.
As someone who has contributed a great deal of time and effort to the geode-for-redis module in the past year or so, it's sad to see it go, but realistically, the last thing that Geode needs is more unmaintained code. Our track record for removing dead or deprecated code is pretty poor, so removing this before it gets a chance to add to the burden seems like a sensible idea. In addition to this, the tests in the geode-for-redis module contribute significantly to the total run time of CI pipeline jobs, particularly the acceptance tests, in which geode-for-redis tests account for over 50% of the total run time.
________________________________
From: Alexander Murmann <am...@vmware.com>
Sent: Thursday, April 14, 2022 5:15 PM
To: geode <de...@geode.apache.org>
Subject: [discuss] Future of the geode-redis module
Hi Geode community!
A while ago engineers from VMware started to improve the geode-redis module that has been in Geode for several years, but never had been completed. This involved adding more tests for existing functionality, as well as adding support for more commands.
VMware will not continue this investment in the geode-redis module. While the geode-redis module is in a much better place than two years ago there still is a lot of work left to make it a viable option for most of our users and the module is still in an experimental state.
For the community this poses the question of what we want to do with the existing code. This work now has been started and stopped twice. All code comes with a maintenance burden which adds up<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fben.balter.com%2F2016%2F07%2F21%2Fremoving-a-feature-is-a-feature%2F&data=05%7C01%7Cdoevans%40vmware.com%7C3d08029d93f8465add5408da1e751bbb%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637855785572189285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GyE2Pj9QlqCtABg2%2BF0VCZ1RRHh5D%2Bm1STb%2B1fwtuAc%3D&reserved=0>. Dependencies might need to be updated; flaky tests fixed and it brings cognitive overhead for us and our users. Unless someone else in the community steps up to take on the task of maintaining the geode-redis module, I propose to remove the code from our develop branch and give everyone more bandwidth to use elsewhere.
Thank you all in advance for your thoughts