You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Mark Hanson <mh...@pivotal.io> on 2020/06/26 17:06:38 UTC
[Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Anilkumar Gingade <ag...@vmware.com>.
+1 As Donal said, complete the feature with all the available APIs.
On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
+1
Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
________________________________
From: Mark Hanson <mh...@pivotal.io>
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark
Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Posted by Dave Barnes <db...@apache.org>.
OK - you've got the votes, Mark, thanks for your contribution.
I'm persuaded by the positive arguments and assurances of low risk.
All: let's focus on getting to RC1. I'm not comfortable with "as this
release has drug on for so long, it might be just about time to reset
expectations". Let's clean up 1.13 and get it out the door.
Thanks,
Dave
On Fri, Jun 26, 2020 at 2:54 PM Owen Nichols <on...@vmware.com> wrote:
> Thank Mark and Donal for detailing the risk and criticality of this
> change. Since 1.13 is still waiting on a couple other issues, might as
> well take the opportunity to bring this in. My vote is +1 now.
>
> On 6/26/20, 2:32 PM, "Donal Evans" <do...@vmware.com> wrote:
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall). So I reject that argument that this is about "including
> the entire feature"
> The "no" regarding the inclusion of a REST api was specifically
> referring to the inclusion of that api's design in the RFC for the restore
> redundancy feature, not whether a REST api for it should exist at all. From
> the RFC: "It is also not within the scope of this RFC to describe any REST
> API that may be created at a future point in time."[1]<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goals&data=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275&sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3D&reserved=0>
> It was always intended to create a REST api for the restore redundancy
> feature, but it was outside of the scope of my knowledge at the time the
> RFC was created to describe it fully there, so the decision was to move
> forward with the "partial" RFC rather than get bogged down in fully
> describing every facet of the feature before beginning implementation.
>
> As for the risk associated with this last stage of the restore
> redundancy feature, as far as I can tell, it's very low. The core changes
> are already in the 1.13 release branch, and have been since mid May, with
> no issues found since then. The proposed changes to be backported to the
> 1.13 release branch merely expose the REST endpoints associated with those
> changes, and don't touch core Geode at all, as far as I'm aware.
>
> [1]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goals&data=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275&sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3D&reserved=0
> ________________________________
> From: Owen Nichols <on...@vmware.com>
> Sent: Friday, June 26, 2020 2:09 PM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: Re: [Proposal] Add REST command for Restore Redundancy to
> 1.13 (GEODE-8095)
>
> When restore-redundancy was first proposed, the question was asked
> whether a REST api would be part of that, and the answer was an emphatic
> "no" (largely due to the continuing "experimental" labeling on the REST
> API, as I recall). So I reject that argument that this is about "including
> the entire feature"
>
> Our "critical fixes rule" notes that our quarterly release cadence
> ensures that there is always an upcoming release vehicle for new features
> -- we will be cutting support/1.14 in just a few weeks on Aug 3. Can you
> make the case that this feature is critical to release sooner? As I
> understand it this feature is just an optimization -- existing code can
> already use the rebalance API to restore redundancy, it just might take a
> little longer.
>
> That said, all you need is three votes, so make your case. Especially
> as we are already 8 weeks past the branch cut of support/1.13, and
> hopefully getting very close to an RC1, concern about risk weighs on my
> mind more than the merits. What level of testing has this been through?
> Does it touch core code? You may be able to get the votes just by
> demonstrating that the risk is very low.
>
> I'm a +0 for this based on the information presented so far.
>
> On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
>
> +1
>
> Although normally features wouldn't really count as "critical
> fixes" that would warrant inclusion after the release branch has been cut,
> in this case, the internal API and gfsh commands for restore redundancy are
> already in the release, and it makes much more sense to include the entire
> feature in one release rather than having a semi-complete feature in 1.13
> and forcing the REST component to wait for a later release.
> ________________________________
> From: Mark Hanson <mh...@pivotal.io>
> Sent: Friday, June 26, 2020 10:06 AM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: [Proposal] Add REST command for Restore Redundancy to
> 1.13 (GEODE-8095)
>
> Hello All,
>
> The core of the restore redundancy call structure has been
> refactored to allow there to be a REST call to invoke a restore redundancy.
> At this point, looking forward to the 1.13 release it would be great if we
> could fit this into the 1.13 release.
>
> What do people think?
>
> Thanks,
> Mark
>
>
>
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Owen Nichols <on...@vmware.com>.
Thank Mark and Donal for detailing the risk and criticality of this change. Since 1.13 is still waiting on a couple other issues, might as well take the opportunity to bring this in. My vote is +1 now.
On 6/26/20, 2:32 PM, "Donal Evans" <do...@vmware.com> wrote:
When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
The "no" regarding the inclusion of a REST api was specifically referring to the inclusion of that api's design in the RFC for the restore redundancy feature, not whether a REST api for it should exist at all. From the RFC: "It is also not within the scope of this RFC to describe any REST API that may be created at a future point in time."[1]<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goals&data=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275&sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3D&reserved=0> It was always intended to create a REST api for the restore redundancy feature, but it was outside of the scope of my knowledge at the time the RFC was created to describe it fully there, so the decision was to move forward with the "partial" RFC rather than get bogged down in fully describing every facet of the feature before beginning implementation.
As for the risk associated with this last stage of the restore redundancy feature, as far as I can tell, it's very low. The core changes are already in the 1.13 release branch, and have been since mid May, with no issues found since then. The proposed changes to be backported to the 1.13 release branch merely expose the REST endpoints associated with those changes, and don't touch core Geode at all, as far as I'm aware.
[1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands%23RedundancyGfshCommands-Anti-Goals&data=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275&sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3D&reserved=0
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Friday, June 26, 2020 2:09 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
Our "critical fixes rule" notes that our quarterly release cadence ensures that there is always an upcoming release vehicle for new features -- we will be cutting support/1.14 in just a few weeks on Aug 3. Can you make the case that this feature is critical to release sooner? As I understand it this feature is just an optimization -- existing code can already use the rebalance API to restore redundancy, it just might take a little longer.
That said, all you need is three votes, so make your case. Especially as we are already 8 weeks past the branch cut of support/1.13, and hopefully getting very close to an RC1, concern about risk weighs on my mind more than the merits. What level of testing has this been through? Does it touch core code? You may be able to get the votes just by demonstrating that the risk is very low.
I'm a +0 for this based on the information presented so far.
On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
+1
Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
________________________________
From: Mark Hanson <mh...@pivotal.io>
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Donal Evans <do...@vmware.com>.
When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
The "no" regarding the inclusion of a REST api was specifically referring to the inclusion of that api's design in the RFC for the restore redundancy feature, not whether a REST api for it should exist at all. From the RFC: "It is also not within the scope of this RFC to describe any REST API that may be created at a future point in time."[1]<https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands#RedundancyGfshCommands-Anti-Goals> It was always intended to create a REST api for the restore redundancy feature, but it was outside of the scope of my knowledge at the time the RFC was created to describe it fully there, so the decision was to move forward with the "partial" RFC rather than get bogged down in fully describing every facet of the feature before beginning implementation.
As for the risk associated with this last stage of the restore redundancy feature, as far as I can tell, it's very low. The core changes are already in the 1.13 release branch, and have been since mid May, with no issues found since then. The proposed changes to be backported to the 1.13 release branch merely expose the REST endpoints associated with those changes, and don't touch core Geode at all, as far as I'm aware.
[1] https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands#RedundancyGfshCommands-Anti-Goals
________________________________
From: Owen Nichols <on...@vmware.com>
Sent: Friday, June 26, 2020 2:09 PM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
Our "critical fixes rule" notes that our quarterly release cadence ensures that there is always an upcoming release vehicle for new features -- we will be cutting support/1.14 in just a few weeks on Aug 3. Can you make the case that this feature is critical to release sooner? As I understand it this feature is just an optimization -- existing code can already use the rebalance API to restore redundancy, it just might take a little longer.
That said, all you need is three votes, so make your case. Especially as we are already 8 weeks past the branch cut of support/1.13, and hopefully getting very close to an RC1, concern about risk weighs on my mind more than the merits. What level of testing has this been through? Does it touch core code? You may be able to get the votes just by demonstrating that the risk is very low.
I'm a +0 for this based on the information presented so far.
On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
+1
Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
________________________________
From: Mark Hanson <mh...@pivotal.io>
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Mark Hanson <ha...@vmware.com>.
I can appreciate your perspective. I think there are three key things when looking at whether or not to add this to the 1.13 release or not.
1) this is a desirable feature that we were hoping to use internally at VMware and with our current release cadence, it is unclear when the next release is that would pick this up.
2) It was not initially expected to go in, but as this release has drug on for so long, it might be just about time to reset expectations for 1.13.
3) Given that that there is unit and DUnit testing in this code I think it is sufficiently tested to not be of significant concern in that regard. The core refactoring is already in 1.13 and this additional feature work is just enabling Restore Redundancy through REST. This work to enable that as mentioned has unit and DUnit tests.
Thanks,
Mark
> On Jun 26, 2020, at 2:09 PM, Owen Nichols <on...@vmware.com> wrote:
>
> When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
>
> Our "critical fixes rule" notes that our quarterly release cadence ensures that there is always an upcoming release vehicle for new features -- we will be cutting support/1.14 in just a few weeks on Aug 3. Can you make the case that this feature is critical to release sooner? As I understand it this feature is just an optimization -- existing code can already use the rebalance API to restore redundancy, it just might take a little longer.
>
> That said, all you need is three votes, so make your case. Especially as we are already 8 weeks past the branch cut of support/1.13, and hopefully getting very close to an RC1, concern about risk weighs on my mind more than the merits. What level of testing has this been through? Does it touch core code? You may be able to get the votes just by demonstrating that the risk is very low.
>
> I'm a +0 for this based on the information presented so far.
>
> On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
>
> +1
>
> Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
> ________________________________
> From: Mark Hanson <mh...@pivotal.io>
> Sent: Friday, June 26, 2020 10:06 AM
> To: dev@geode.apache.org <de...@geode.apache.org>
> Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
>
> Hello All,
>
> The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
>
> What do people think?
>
> Thanks,
> Mark
>
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Owen Nichols <on...@vmware.com>.
When restore-redundancy was first proposed, the question was asked whether a REST api would be part of that, and the answer was an emphatic "no" (largely due to the continuing "experimental" labeling on the REST API, as I recall). So I reject that argument that this is about "including the entire feature"
Our "critical fixes rule" notes that our quarterly release cadence ensures that there is always an upcoming release vehicle for new features -- we will be cutting support/1.14 in just a few weeks on Aug 3. Can you make the case that this feature is critical to release sooner? As I understand it this feature is just an optimization -- existing code can already use the rebalance API to restore redundancy, it just might take a little longer.
That said, all you need is three votes, so make your case. Especially as we are already 8 weeks past the branch cut of support/1.13, and hopefully getting very close to an RC1, concern about risk weighs on my mind more than the merits. What level of testing has this been through? Does it touch core code? You may be able to get the votes just by demonstrating that the risk is very low.
I'm a +0 for this based on the information presented so far.
On 6/26/20, 11:50 AM, "Donal Evans" <do...@vmware.com> wrote:
+1
Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
________________________________
From: Mark Hanson <mh...@pivotal.io>
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark
Re: [Proposal] Add REST command for Restore Redundancy to 1.13
(GEODE-8095)
Posted by Donal Evans <do...@vmware.com>.
+1
Although normally features wouldn't really count as "critical fixes" that would warrant inclusion after the release branch has been cut, in this case, the internal API and gfsh commands for restore redundancy are already in the release, and it makes much more sense to include the entire feature in one release rather than having a semi-complete feature in 1.13 and forcing the REST component to wait for a later release.
________________________________
From: Mark Hanson <mh...@pivotal.io>
Sent: Friday, June 26, 2020 10:06 AM
To: dev@geode.apache.org <de...@geode.apache.org>
Subject: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
Hello All,
The core of the restore redundancy call structure has been refactored to allow there to be a REST call to invoke a restore redundancy. At this point, looking forward to the 1.13 release it would be great if we could fit this into the 1.13 release.
What do people think?
Thanks,
Mark