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 <onich...@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" <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 >
