On 2007-04-05T07:40:34, Alan Robertson <[EMAIL PROTECTED]> wrote: > > That is why I'd suggest to only call it in start or post-notify; calling > > it in post-notify basically implies it'll be called after every state > > change. > But, for DRBD for example, the ability to become master can change > without a heartbeat state change.
I didn't say it was perfect ;-) As even calling crm_master and having it do a compare and update-if-modified, or filtering it in the CIB directly requires to at least contact and query the CIB, I'd probably still track the state in the RA somewhere. (As to avoid forking and IPC.) Or even better, monitoring drbd via a daemon which sends an async notification (either a crm_master change or a async failure notification) when something happens, instead of polling via the LRM. I'd wish to have a "fast" LRM interface, where the instantiation of a resource starts a sub-daemon to control it and then manage it via IPC (or maybe stdin/stdout) with that process - and, if the daemon support it, have it do async monitoring as well. Hmmm. I think we have a bugzilla for that since ages, and now we have a full-time LRM maintainer again as well ;-) Among with the LRM-needs-to-track-timestamps, this is probably one of the most important features I'm missing in the LRM ... (The CIB modification to filter out unnecessary changes is of course good in any case.) Sincerely, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/