The RFC has been updated in response to the feedback given so far. Description of the behaviour of the gfsh commands regarding success/failure cases has been expanded, and the internal API has been updated to reflect the use of a CompletableFuture instead of the originally proposed RestoreRedundancyOperation.
Thank you all for your input. On Wed, Apr 1, 2020 at 10:46 AM Donal Evans <doev...@pivotal.io> wrote: > - If a PR is configured with redundant-copies=0 and I run a restore >> redundancy operation, will I get an error? >> - Will I get an error if I run this operation when no partitioned regions >> exist? > > > A PR configured with zero redundancy will return success status. > > There's a subtlety with the second no-op case though, since you could have > a situation where you call the command with no arguments (include all > regions) and don't find any partitioned regions, which would be fine, or > you could have a situation where you explicitly include some regions and > none of them are found, in which case I'm not sure that returning success > would be correct. Would it be reasonable to return error in the case that > all explicitly included region aren't found? > > On Wed, Apr 1, 2020 at 9:16 AM Aaron Lindsey <aaronlind...@apache.org> > wrote: > >> > If at least one redundant copy exists for every bucket in the specified >> regions, the status of the command will be success. If at least one bucket >> in a region has zero redundant copies, if there is a member in the system >> with an older version of Geode or if the restore redundancy function >> encounters an exception, the command will return error status. >> >> - If a PR is configured with redundant-copies=0 and I run a restore >> redundancy operation, will I get an error? >> - Will I get an error if I run this operation when no partitioned regions >> exist? >> >> I think the proposal should address what should happen in a no-op >> scenario like the two cases above. I think it should return success in >> these cases because the operation did not fail, it just didn’t have to do >> anything to achieve the desired outcome. The reasoning is that this >> operation will be invoked programmatically to ensure data is redundant >> before shutting down a member. So it would be run “just in case”, not >> because we actually know there is data which needs to have redundancy >> restored. >> >> I also +1 Kirk’s idea of using CompletableFuture >> >> >> Aaron >> >> >> > On Mar 31, 2020, at 7:46 AM, Joris Melchior <jmelch...@pivotal.io> >> wrote: >> > >> > +1 >> > >> > I like this idea and Kirk's suggestion to use the CompletableFuture as a >> > standard for asynchronous operations. >> > >> > On Mon, Mar 30, 2020 at 2:47 PM Donal Evans <doev...@pivotal.io> wrote: >> > >> >> Hey everyone, >> >> >> >> An RFC for adding gfsh commands to allow users to restore redundancy to >> >> partitioned regions and to easily check the redundancy status of >> >> partitioned regions has been posted: >> >> >> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands >> >> . >> >> >> >> Please review and comment on this RFC by Monday, 04/06/2020. >> >> >> >> Please also note that this RFC has been revised from an earlier draft >> >> version that some of you may have seen, so the content may have >> changed. >> >> >> >> Thanks, >> >> Donal >> >> >> > >> > >> > -- >> > *Joris Melchior * >> > CF Engineering >> > Pivotal Toronto >> > 416 877 5427 >> > >> > “Programs must be written for people to read, and only incidentally for >> > machines to execute.” – *Hal Abelson* >> > <https://en.wikipedia.org/wiki/Hal_Abelson> >> >>
