On 1/21/06, Peter Kruse <[EMAIL PROTECTED]> wrote:
> 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.
It wont cause fail-over - because we cant perform any actions on
unmanaged resources.
So resources that have colocational constraints with the failed
resource will also not be migrated since the original failure cant be.
One thing to keep in mind is that if we stop monitoring a resource
when its not managed then the resources that sit on top of it may be
adversely affected since they now don't know that its prerequisite is
starting/stopping.
> >>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/
>
_______________________________________________________
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/
