Alan Robertson <[EMAIL PROTECTED]> writes: > Andrew Beekhof wrote: >> On 4/17/07, Keisuke MORI <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> The official document on the web mentions about how to >>> distinguish between probe and monitor that you can tell by >>> referring to the value of OCF_RESKEY_CRM_meta_interval >>> as cited below. >>> >>> But as long as I tested, OCF_RESKEY_CRM_meta_interval is not set >>> only when probe. (for regular monitors, it is set correctly.) >>> >>> Which behaviour is correct? >> >> it wouldn't be hard to set it (and even if not, then the expression >> could be modified slightly)... the real question however is: why do >> you think you need to know? >> >> any variable starting with OCF_RESKEY_CRM_meta_ is an internal value >> that the RAs etc shouldn't need to know about. > > The OCF standard says _nothing_ about these variables. We create them, > but you shouldn't use them. > > The probe and the monitor are asking EXACTLY the same question: > > Is the resource running? > > The answer should be the same in the probe and the monitor cases. > > If they're not, then either your code is broken, or you're playing some > fancy tricks which will eventually come back to bite you sometime in the > future. > > Or perhaps you misunderstand something. > > Answering Andrew's question above would help clarify which: > "Why do you think you need to know?"
What I want to do is similar to MailTo RA, which is a pseudo RA that has no acutual application to be monitored, and is just for executing some commands when start/stop along with resources grouped together. I also want to run some commands for periodic monitors during it's active. In this pseudo RA, probe should always return OCF_NOT_RUNNING otherwise start will not be called, and periodic monitors should return OCF_SUCCESS usually. Probably I'm doing tricky thing as you said, but I believe what I want to do is simple... -- Keisuke MORI NTT DATA Intellilink Corporation _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
