[Pacemaker] Enable remote monitoring

[Lars Marowsky-Bree]

On 2012-11-09T17:06:32, David Vossel <dvossel at redhat.com> wrote:

OK, I should first have read the whole thread. Sorry about that. Brain
whacko.

> > It needs to be a new class because the scripts (I'm pretty sure)
> > follow a completely different API to anything else we support.

Right. That's what I meant, of course. Not what I wrote! ;-)

> Yep, I'm convinced.  Looking what is actually going on to make a
> group, we'd probably break the world if we overloaded it with this new
> stuff. Sorry for getting us sidetracked.  I just like to start by
> making sure we can't leverage work we've already done before talking
> about all this new stuff.

Ok, so not a group. I'm fine with that.

I could also imagine this to be a special flag on the ordering
dependency:

Status quo: order A->B implies B is started after B. If B fails, nothing
happens with A.

We want "A" to be restarted if "B" fails. (If A->B are also collocated,
we'd also get fail-over after migration-threshold triggers. That may not
always be desired.)

A "restart-origin" attribute, perhaps?

> Does the order in which the members of the container start monitoring
> matter?  Do the members need to be serialized or anything, or can we
> just start the container parent, then assume it is okay to start all
> the container members? Having the internal constraints only interact
> between the parent and children resources makes this less complex.

Concurrency ought to be safe. But for the cases where this is not
desired, they can chain dependencies anyway.

(i.e., if they do
"order foo inf: vm1 (a b c) restart-container=true"
versus
"order vm1 a b c")

> Also, how many of these nagios resources do you think will live per a container?

Probably 1-3.


Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde