On Thu, Jul 10, 2008 at 08:05, Joe Bill <[EMAIL PROTECTED]> wrote: > > --- On Wed, 7/9/08, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > >>> Or, in other words, are all 4 return codes necessary, >>> if all we want in all 4 cases is to trigger a hard reset ? >> >> programatically, not really. >> but if i'm an admin trying to figure out why the >> resource wont run on a given node anymore, i'm sure >> i'd appreciate them not being merged. > > That I fully understand. But shouldn't these conditions be described > independently from the condition status, through, i.e. a condition code ?
I don't understand. The RA should tell us what happened. End of story. What this documents is what the cluster will do based on what the RA told us. Telling the cluster what you think it wants to hear always leads to tragedy. Just tell the truth. > >> at any rate, these return codes are part of the OCF spec. >> we're just following it and indicating what type of >> recovery we do for each. > > I also understand that and that's why I was precisely saying mixing a > condition with it's severity or it's handling was not a good idea for the > reasons I already gave. > > Right now, the OCF return status code only uses 9 values out of 256 the > return status allows, or in other words 4 bits out of 8. > > For an improved scheme, why not use the lower bits to describe the condition > as they are described today, with the exception of values 0 and 1 which > describe generic success and error codes, and the higher 4 bits to describe > the severity and handling ? Maybe, but I don't write the spec and personally I don't think the RA should be telling the cluster what type of recovery to perform. That's a policy decision that should be made by the Policy Engine. As above, just tell us what happened and let the cluster decide what to do. > > One can also imagine, if the high bits aren't used, use the current scheme, > and if the high bits are used using the improved scheme. > > > > > _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
