[Pacemaker] Enable remote monitoring

[Gao,Yan]

On 12/04/12 06:20, Lars Marowsky-Bree wrote:
> On 2012-12-03T16:32:14, David Vossel <dvossel at redhat.com> wrote:
> 
>>> +      <optional>
>>> +	<attribute name="restart-origin"><data type="boolean"/></attribute>
>>> +      </optional>
>>
>> I don't feel strongly about this. Here's what comes to mind for me.
>>
>> force-recover - force recovery of both sides of the constraint if either side fails
> 
> We actually have a precedent here - grep for restart_type. ;-)
> 
> "force-recover" doesn't quite fit for me; because for the first->then
> distinction, we already have the 0 versus inf score differentiation.
> What would force-recover do for score=0?
> 
> (Ohhh. Did we just find a use for a negative score here? ;-) Just
> throwing that out there. It'd fit the model we have so far, is all I'm
> saying.)
Perhaps to name another "kind" for order constraint instead of an
additional optional attribute?

> 
> But - I think restarting alone doesn't suffice. Do we want to have the
> restarts count towards the migration-threshold of the parent resource
> too? I think we may want that.
> 
> If we want to stick with the terminology, "restart-first" (but -origin
> sounds better, so I don't feel that strongly either) as a tri-state (no
> (default), yes, treat-as-failure (anyone got a snappy idea for that
> one?) might make be advisable.
> 
> 
>> Here's a thought.  Add the new constraint flag as well as a new option on the primitive that escalates failures to the parent resource (pretty sure this idea isn't mine, maybe Andrew threw it at me a few weeks ago)
>>
>> Then you could do something like this.
>>
>> primitive vm
>> group vm-resources
>>     primitive nagios-monitor-foo
>>     primitive nagios-monitor-bar
>>
>> order vm then vm-resources reset-origin
>> colocation vm vm-resources.
>>
>>
>> It isn't as simple (configuration wise, not implementation wise) as the container concept, but at least this way you don't have to build relationships between the vm and every resource in it explicitly.  It seems like leveraging groups here would be a good idea.
> 
> One the one hand, this makes a lot of sense.
> 
> But when we're going this far, why not directly:
> 
> group vm-with-resources vm nagios-monitor-foo nagios-monitor-bar \
> 	meta restart-origin="true"
> 
> ? All we'd be doing is flip the restart-origin bit on the orders
> implicit in the group.
If "group" has already been tortured enough, like Andrew said :-) , then
we don't have to use group in either way.  If we really need some kind
of "container", how about we just use resource_set:

order vm-then-rscs inf: vm (nagios-foo nagios-bar) \
      restart-origin="true"
colocation rscs-with-vm inf: (nagios-foo nagios-bar) vm


The order's XML is like:

<rsc_order id="vm-with-rscs" restart-origin="true">
  <resource_set id="vm-origin">
    <resource_ref id="vm"/>
  </resource_set>
  <resource_set id="vm-rscs" sequential="false" >
    <resource_ref id="nagios-foo"/>
    <resource_ref id="nagios-bar"/>
  </resource_set>
</rsc_order>

Or maybe someone wants the nagios resources to be serialized:

<rsc_order id="vm-then-rscs" restart-origin="true">
  <resource_set id="vm-and-rscs" sequential="true" >
    <resource_ref id="vm"/>
    <resource_ref id="nagios-foo"/>
    <resource_ref id="nagios-bar"/>
  </resource_set>
</rsc_order>

Regards,
  Gao,Yan
-- 
Gao,Yan <ygao at suse.com>
Software Engineer
China Server Team, SUSE.