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@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker _______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker
