Since the deadline for feedback has been reached and there have been no objections to the proposed changes, this RFC has been moved to "In Development" status.
Be on the lookout for a PR containing the internal Java API later today! On Thu, Apr 2, 2020 at 10:16 AM Aaron Lindsey <aaronlind...@apache.org> wrote: > Yes, thanks for clarifying. > > > On Apr 2, 2020, at 10:12 AM, Donal Evans <doev...@pivotal.io> wrote: > > > > Re-sending this from the correct email address. I think the original got > > eaten. > > > > > >> From the RFC: > >>> The command will return error status if: > >> I assume this means ERROR or FAILURE (non-success) status. It seems a > >> little confusing that there are both ERROR and FAILURE statuses. Maybe > you > >> could add another section, “the command will return failure status if:” > to > >> make it clear when it will be returning an error vs a failure. I think > this > >> will be important for users who are triggering the redundancy restore > >> operation programmatically to understand the difference. > > > > > > This is a little confusing, unfortunately. The issue arises from the fact > > that in addition to the Status of the RestoreRedundancyResults, which can > > be SUCCESS, FAILURE or ERROR and describes the status of a restore > > redundancy operation on one member, a gfsh command can only return either > > SUCCESS or ERROR result statuses when it is called, which represent the > > status of the command across all members. The result status of the > command > > and the Status of the RestoreRedundancyResults are separate things, > > although the command's result status will be partially determined from > the > > Status values of the RestoreRedundancyResults objects returned by > function > > execution on each member. > > > > The differentiation between FAILURE and ERROR status for > > RestoreRedundancyResults is relevant, since there should be different > > behaviour for "we were unable to create a redundant copy for all buckets > in > > a region," which may be due to not enough members hosting that region or > > some other relatively benign problem, and "we encountered an exception > > while attempting to restore redundancy and were unable to complete the > > operation," which could be indicative of a more serious issue. > > > > I hope this clarifies things somewhat. > > > > On Thu, Apr 2, 2020 at 8:44 AM Aaron Lindsey <aaronlind...@apache.org> > > wrote: > > > >>> Would it be reasonable to return error in the case that > >>> all explicitly included region aren't found? > >> > >> Yes, this sounds reasonable. Thanks for pointing out that subtlety and > for > >> updating the RFC. > >> > >> From the RFC: > >>> The command will return error status if: > >> > >> I assume this means ERROR or FAILURE (non-success) status. It seems a > >> little confusing that there are both ERROR and FAILURE statuses. Maybe > you > >> could add another section, “the command will return failure status if:” > to > >> make it clear when it will be returning an error vs a failure. I think > this > >> will be important for users who are triggering the redundancy restore > >> operation programmatically to understand the difference. > >> > >>> On Apr 2, 2020, at 5:18 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > >>> > >>> > >>> > >>>> On Apr 1, 2020, at 10:46 AM, Donal Evans <doev...@pivotal.io> wrote: > >>>> > >>>> 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 > >>> > >>> I think in this case it is not an error since all would mean all that > >> this may apply to. > >>> > >>>> 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? > >>> > >>> I believe this should be the behavior. If any one explicitly listed > >> region does not exist an error should result. > >>> > >>> -Jake > >>> > >> > >> > >
