Good morning,
Lars Marowsky-Bree wrote:
>On 2006-01-20T12:37:10, Peter Kruse <[EMAIL PROTECTED]> wrote:
>
>
>OK, this we'll eventually provide again. (ipfail)
>
>
except that ipfail relies on an external address, but
I don't understand why the failure of an external address
should cause a failover. Even if you use multiple addresses
to ping.
>However, that's pretty close to how we eventually want to support this.
>If you already have the ifmonitord written, it'd be a small step for you
>to actually feed this into the CIB as dampened node attributes, right
>(instead of doing it within the resource agent)? And then we could
>handle this internally, and you claim to have contributed a major
>feature to heartbeat 2.0.x! ;-)
>
>
>
Sure, I would love that. But it's written in bash,
and uses our own scripting library and ... you know ...
"it works for us"... meaning we probably won't have
the resources to support it. If you want to have a look
at it however, I can send it to you, there are some
ideas we took from the Failsafe agents, you will
recognize.
>Uhm, that is already supposed to exist within the CRM, if you set a
>resource to unmanaged. We probably need an in-between state of "not
>monitored" (or monitor failures ignored) instead of completely unmanaged
>though.
>
>
That's what I thought, too. If you set a resource group
to unmanaged, the monitor actions are still called
and failures are still recognized. But not sure
if it causes a failover.
>>3. you can set the maximum number of restarts before a real
>>failover occurs, this is also stored in the cib.
>>
>>
>
>This _definetely_ belongs into a generic feature within the CRM.
>Handling it within the RA is not the right place. We have an AI for it,
>ETA is 2.0.3 or 2.0.4 (Andrew?).
>_If_ you're handling it within the RA, there's no point in storing it
>within the CIB. That's a waste, because the CIB sync is pretty
>expensive.
>
>Set an instance parameter (which you'll then get within your environment
>of course) and keep track of the number of local restarts within a file
>under ${HA_RSCTMP} (that get's cleaned out on reboots).
>
>
>
Hm, ... yes, that's an idea, don't know why I thought it
has to be stored in the cluster database. That I probably
will change, thanks.
Peter
_______________________________________________________
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/
