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/
