[ClusterLabs] PCMK_OCF_DEGRADED (_MASTER): exit codes are mapped to PCMK_OCF_UNKNOWN_ERROR

Ken Gaillot kgaillot at redhat.com
Mon Mar 6 18:49:42 EST 2017


On 03/06/2017 04:15 PM, Lars Ellenberg wrote:
> On Mon, Mar 06, 2017 at 12:35:18PM -0600, Ken Gaillot wrote:
>>>>>> diff --git a/lrmd/lrmd.c b/lrmd/lrmd.c
>>>>>> index 724edb7..39a7dd1 100644
>>>>>> --- a/lrmd/lrmd.c
>>>>>> +++ b/lrmd/lrmd.c
>>>>>> @@ -800,11 +800,40 @@ hb2uniform_rc(const char *action, int rc, const char *stdout_data)
>>>>>>  static int
>>>>>>  ocf2uniform_rc(int rc)
>>>>>>  {
>>>>>> -    if (rc < 0 || rc > PCMK_OCF_FAILED_MASTER) {
>>>>>> -        return PCMK_OCF_UNKNOWN_ERROR;
>>>>
>>>> Let's simply use > PCMK_OCF_OTHER_ERROR here, since that's guaranteed to
>>>> be the high end.
>>>>
>>>> Lars, do you want to test that?
>>>
>>> Why would we want to filter at all, then?
>>>
>>> I get it that we may want to map non-ocf agent exit codes
>>> into the "ocf" range,
>>> but why mask exit codes from "ocf" agents at all (in lrmd)?
>>
>> It's probably unnecessarily paranoid, but I guess the idea is to check
>> that the agent at least returns something in the expected range for OCF
> 
> Well, yes. But, if we are going to allow the range 0 to 199,
> I don't see any reason to hide the range 200 to 255.

Ideally, all non-LSB OCF return codes should be in the LSB spec's
150-199 range reserved for application use, since OCF aims for some
degree of LSB compatibility. RUNNING_MASTER and FAILED_MASTER got into
the wild before that policy was set, so they're exceptions. But it's
reasonable to require that all future OCF codes fall into that range.

>> (perhaps it's not complying with the spec, or complying with a newer
>> version of the spec than we can handle).
> 
> Or, as in the case of PCMK_OCF_DEGRADED, complying with a newer version
> of the spec that probably would have been handled fine, if it wasn't for
> the unneccesary paranoia ;-)
> 
>     Lars




More information about the Users mailing list