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