Lars Marowsky-Bree wrote:
> 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.)
Keeping track of it in the RA would typically involve extra forking to
do the query, and comparision, and also to manage the state in tmp
files, etc.
> 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.
Invoking the LRM to update the CIB isn't more efficient than just
updating the CIB.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
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/
