[Pacemaker] Enable remote monitoring

[Andrew Beekhof]

On 05/12/2012, at 11:27 PM, "Gao,Yan" <ygao at suse.com> wrote:

> 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.

Does that make sense though?
You've not achieved anything a restart wouldn't have done.
The choice to move the VM should be up to the VM.

> 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.
> 
> _______________________________________________
> 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