Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
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 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" 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-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=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-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0 > ____________ > From: Owen Nichols > Sent: Friday, June 26, 2020 2:09 PM > To: dev@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" wrote: > > +1 > > Although normally features wouldn't really count as "critical > fixes" that would warrant inclusion after the release branch has been cut,
Re: [Proposal] Add REST command for Restore Redundancy to 1.13 (GEODE-8095)
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" 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-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=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-Goalsdata=02%7C01%7Conichols%40vmware.com%7C1b3013cdfe2e4a25e52808d81a1868ac%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637288039421320275sdata=7btBLHCWstbBEEJfio%2Bc2X41AWigVmcdh%2FcF9SQQRQI%3Dreserved=0
From: Owen Nichols
Sent: Friday, June 26, 2020 2:09 PM
To: dev@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" 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
Sent: Friday, June 26, 2020 10:06 AM
To: dev@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
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"
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
Sent: Friday, June 26, 2020 2:09 PM
To: dev@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" 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
Sent: Friday, June 26, 2020 10:06 AM
To: dev@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)
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 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" 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 >Sent: Friday, June 26, 2020 10:06 AM >To: dev@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)
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" 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
Sent: Friday, June 26, 2020 10:06 AM
To: dev@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)
+1 As Donal said, complete the feature with all the available APIs.
On 6/26/20, 11:50 AM, "Donal Evans" 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
Sent: Friday, June 26, 2020 10:06 AM
To: dev@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)
+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 Sent: Friday, June 26, 2020 10:06 AM To: dev@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
[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
