[Pacemaker] Enable remote monitoring

[Gao,Yan]

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 ;-)

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

I'm not sure if we should relate the restarts count with the
migration-threshold of the basic resource. 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.


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.