On Thu, Jul 01, 2010 at 03:52:31PM +0100, Luca Bigliardi wrote: > On Thu, Jul 1, 2010 at 3:34 PM, Iustin Pop <[email protected]> wrote: > > > Hrmm… That's a weird way to use the rpc interface. Why are you not > > simply returning the string, and _Fail() in case you get a block device > > error (in patch 7/12)? > > > > Note it is a valid way to use it, but in that case (since you're not > > using the validation routines in rpc.py), you need to validate yourself > > the tuple received, etc. In other words, what advantage do you get from > > having two status fields? > > Well I would like to be able to proceed if a node/net health problem occurs, > but raise an error if the node is misconfigured (in this way a drbd module > not loaded triggers the error).
I understand your point, but I'm not sure if this is a good idea. The temporary failure could be hiding the fact that the node might be healthy and have the wrong helper, etc. I would rather say: - any failure aborts the operation: per the other code, broken nodes should be offlined anyway (and yes, you need to skip an offline node) - optionally, failures could be forced via the --force flag iustin
