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 <onich...@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" <doev...@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 <onich...@vmware.com> > Sent: Friday, June 26, 2020 2:09 PM > To: dev@geode.apache.org <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" <doev...@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 <mhan...@pivotal.io> > Sent: Friday, June 26, 2020 10:06 AM > To: dev@geode.apache.org <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 > > >
