[Pacemaker] Resource agents: parameter type enforcement and normalization

[Dejan Muhamedagic]

Hi Florian,

On Fri, Jul 03, 2009 at 08:55:21AM +0200, Florian Haas wrote:
> 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.

AFAIK, CRM doesn't enforce anything. But, I'd say that that
should be done by the validator (RNG scheme or whatever else
deals with XML).

> 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

This is probably only possible by tweaking values in the CRM
before exporting them as variables.

> 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.

Looked a bit around and found that there was an enum once in the
OCF standard and also defined in ra-api-1.dtd. There was also an
example for the Filesystem RA meta-data. Then it was removed.
Perhaps Lars knows why (he is the author). Lars?

Thanks,

Dejan

> 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
> 
> 



> _______________________________________________
> Pacemaker mailing list
> Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker