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 <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
