[Pacemaker] Enable remote monitoring

[David Vossel]

----- Original Message -----
> From: "Yan Gao" <ygao at suse.com>
> To: pacemaker at oss.clusterlabs.org
> Sent: Wednesday, December 5, 2012 6:27:05 AM
> Subject: Re: [Pacemaker] Enable remote monitoring
> 
> Hi,
> This is the first step - the support of "restart-origin" for order
> constraint along with the test cases:
> 
> https://github.com/gao-yan/pacemaker/commits/restart-origin
> 
> It looks straight-forward to me. Hope I didn't miss anything ;-)

I had made some in-line comments for you in git-hub.  It looks like you are on the right track.  I'm just not sure about the symmetrical=false use case for order constraints.

> 
> If restart-origin="true" combines with kind="Optional", it just means
> "Optional". So that a failed nagios resource would not affect the vm.

I agree, restart-origin is a no-op for advisory ordering. 

> 
> I'm not sure if we should relate the restarts count with the
> migration-threshold of the basic resource.

I don't know what the "basic resource" refers to here.  If we are talking about counting the restarts of the vm towards the migration-threshold, I'd expect the vm to have the same behavior as whatever happens to 'B' right now for the use-case below.

Start A then Start B. When A fails restart B.  

Start vm then Start nagios. When nagios fails restart vm.


> Even without this, users
> can
> specify  how many failures of a particular nagios resource they can
> tolerate on a node, the vm will migrate with it anyway.
> And probably we
> could have one of the nagios resources, no matter how many times it
> fails, we just don't want the vm to migrate because of it.

I don't understand this last sentence.

-- Vossel

> 
> 
> On 12/05/12 06:05, Lars Marowsky-Bree wrote:
> > On 2012-12-04T14:48:50, David Vossel <dvossel at redhat.com> wrote:
> > 
> >> The resource ordered set with the 'restart-origin' option gets us
> >> half way there in the constraint definition.  We still have to
> >> build the colocation set between the vm and the resources so
> >> everything runs on the same node (perhaps I just assumed that was
> >> necessary, correct me if I am wrong)
> > 
> > Right, we end up with two resource sets.
> > 
> > (Unless we allow the "restart-origin" to be set for the order
> > constraints that are implicit if a colocation resource set is used
> > with
> > sequential=true. Ouch.)
> Ouch
> 
> > 
> > 
> >> The above is "usable", but it requires the user to explicitly set
> >> up
> >> and manage multiple constraint definitions.  It seems to me like
> >> we
> >> will eventually want to simplify this process.  When that time
> >> comes,
> >> I just want to make sure we approach building the simplified
> >> abstraction at the configuration level and have the management
> >> tools
> >> (crm/pcs) be a transparent extension of whatever we come up with.
> > 
> > For what it is worth, I'd agree with this; the fact that the most
> > common
> > constraints are order *AND* colocation and we don't have a
> > (link|chain|join) statement that adequately provides that has been
> > annoying me for a while. ;-) I massively appreciate that we do have
> > the
> > separate dimensions, and people use that - but still, the
> > combination of
> > both is extremely common.
> > 
> > The independent order + colocation statements do allow for that
> > though;
> > and in theory, a frontend *could* detect that there's both "A
> > first,
> > then B" and "B where A is" with the same priority and present it
> > merged
> > as:
> > 
> > 	join id-494 inf: A B
> Looks neat :-)
> 
> Regards,
>   Gao,Yan
> --
> Gao,Yan <ygao at suse.com>
> Software Engineer
> China Server Team, SUSE.
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started:
> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>