On 4/11/07, Alan Robertson <[EMAIL PROTECTED]> wrote:
Lars Marowsky-Bree wrote:
> On 2007-04-10T07:09:44, Alan Robertson <[EMAIL PROTECTED]> wrote:
>
>>> 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.
>
> Uhm. Forking?
>
> echo, read, and even sourcing the file (if it's written in VAR=VALUE
> style) doesn't incur that overhead.
>
> Anyway, Andrew fixed it in the CIB by now, so this part of the
> discussion is mood ;-)
>
>>> 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.
>
> That is not what this suggestion is about. Try reparsing it ;-)
>
> Such a daemon would obviously easily keep internal state and only issue
> CIB updates or async (failure) notifications as needed. It'd avoid a lot
> of forking for various operations.
You can already do that. Resources often have processes associated with
them. They can update the CIB any time they like. What those processes
do, we don't know, and we don't much care.
Async LRM failure notifications (as failed async monitors) are not there
yet, but there was something about this in the previous discussion that
I've forgotten :-(.
Actually if you look at CTS, you'll find that ResourceRecover uses
a-sync notifications (albeit with a couple of tricks to work around
deficiencies in the lrm)
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
