[sheepdog] [PATCH v2 3/4] sheep: handle block/unblock/notify error

Kai Zhang kyle at zelin.io
Tue Jul 9 04:33:12 CEST 2013


On Jul 9, 2013, at 10:26 AM, Liu Yuan <namei.unix at gmail.com> wrote:

> On Tue, Jul 09, 2013 at 10:15:50AM +0800, Kai Zhang wrote:
>> 
>> On Jul 9, 2013, at 8:43 AM, MORITA Kazutaka <morita.kazutaka at gmail.com> wrote:
>> 
>>> I think block/unblock/notify should return SD_RES_xxx since they know
>>> the error reason rather than the callers.  Currently, all the
>>> callbacks only can return SD_RES_CLUSTER_ERROR or SD_RES_SUCCESS,
>>> though.
>> 
>> 
>> Here is my personal opinion.
>> 
>> I think SD_RES_xxx is used as return code to external module (other sheep and client)
>> to indicate the error of a request.
> 
> No, we don't have this assumption. Mostly we recommend return SD_RES_XXX between
> functions and modules, return -1, 0 only if it is hard to do so.
> 
>> However, block/unblock/notify are internal functions who don't know they are serving for
>> external requests.
>> I think, we can indicate internal error by logging and only use return code '-1' when fail.
>> It is the caller's responsible (here the caller is queue_cluster_request) to mark the result
>> as SD_RES_xxx.
>> 
>> The drawback is that we cannot know the specific error from return code.
>> However, as an internal function, I think only use 0 and -1 as return code is enough.
> 
> You already said the benefit, even though currently return 0 and -1 equal SD_RES_XXX
> because we only have binary ret state, but in the long run, we might add more
> ret state in the future.
> 

I see.
So I think we should also return SD_RES_xxx for init/join/leave/update_node.
I would like to update them in a separate patch later.

Thanks,
Kyle


More information about the sheepdog mailing list