[Pacemaker] Resource agents: parameter type enforcement and normalization

[Florian Haas]

Hello,

continuing a discussion I started, briefly, with Andrew and Dejan yesterday.

As I hear from Andrew, when we define parameters in resource agents and
describe them in the RA metadata information, then the CRM will in fact
do nothing to actually enforce parameter types in the CIB. Instead, that
metadata is intended simply as a hint for the GUI or the CRM shell, and
parameter type enforcement is left to them. In other words, if a
parameter is declared as 'content type="integer"' and one enters a
string in that place in the CIB, then it will happily pass validation.
It would be up to the GUI or CRM shell to catch that configuration
error, if at all. Andrew, Dejan, correct me if I'm wrong.

Now considering the CIB already does, for example, IDREF validation, I
really wonder why it shouldn't be doing content validation as well.
Thereby one could make sure that, for example, something that is
expected to be passed in as integer, is in fact an integer, and we could
stop doing stupid tests in the RAs such as this one:

# Do we have a valid target ID?
[ $OCF_RESKEY_tid -ge 1 ]
case $? in
    0)
        # OK
        ;;
    1)
        ocf_log err "Invalid target ID $OCF_RESKEY_tid (must be greater
than 0)."
        return $OCF_ERR_CONFIGURED
        ;;
    *)
        # this is the utterly braindead part
        ocf_log err "Invalid target ID $OCF_RESKEY_tid (must be an integer)\
."
        return $OCF_ERR_CONFIGURED
esac

If I didn't have to test for it to actually be an integer, I could simply do

[ $OCF_RESKEY_tid -ge 1 ] || return $OCF_ERR_CONFIGURED

... and be done with it.


Likewise, we could finally have something like normalized booleans.
Because I find this sort of tests even more braindead than the above
mentioned one:

case $OCF_RESKEY_force_stop in
    [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1)
        op="destroy"
        ;;
    *)
        op="shutdown"
	;;
esac

Now if the CRM *knew* that this was a boolean, it could simply normalize
that value into "true"/"false", "1"/"0", or (my preference) "true"/"",
and stick that into the appropriate OCF_RESKEY_* environment variable.
I'd like to be able to just do

if [ -n "$OCF_RESKEY_force_stop" ]; then
    op="destroy"
else
    op="shutdown"
fi

... and not worry about whether the boolean was passed in as "yes",
"no", "on", "off", "0", "1" or any upper or mixed case variants of the
same. As long as it's set, I could take that as a "true" value; if it's
unset, then it's false. (Which would of course imply that boolean RA
parameters are always false by default, which may or may not be
desirable, and that may still be discussed, but you get the point.)


And finally, I really want enum support for resource agents. And, this
I've not made myself clear about yesterday, my question is _not_ how to
implement this in the shell or GUI, my question is how to express the
following in the RA metadata XML: this parameter is named "foobar", it's
expected to be passed in as a string, and the allowed values are
"alpha", "bravo", and "charlie".

At this time appears to be supported for cluster properties like
no-quorum-policy (freeze|stop|ignore|suicide), but not for resource
agent parameters. And if it's not even expressible in the metadata, I
don't see how the GUI or the shell should know about it.


All of these are possibly feature requests not for the 1.0 series but
for 1.1, but I'd like to hear people's thoughts about it anyway.

Cheers,
Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.clusterlabs.org/pipermail/pacemaker/attachments/20090703/f54912c2/attachment-0002.sig>