[Pacemaker] Enable remote monitoring

[Andrew Beekhof]

On 04/12/2012, at 9:20 AM, Lars Marowsky-Bree <lmb at suse.com> 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. ;-)

Not a very good precedent though.  I believe it was bad enough that I removed it from the docs.
Although I would support refining the idea into something a bit saner that also handled this case.

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

Scores are deprecated for ordering constraints.
Mostly because they make no sense :-)

We do have 'kind' though.

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

What about inherit-failure = true|false?

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

Right.  Apart from the name.  Really not crazy on "origin".
There's really nothing (apart from a naming convention) to suggest that "origin" means the vm resource.

If we go this way, how about something like propagate-failure=bool or delegate-failure=bool, or just simply: failure-delegate=${resource_name}.
The last one is probably now my favourite, even a trained monkey should be able to figure out what that construct implies :)

> 
> ? All we'd be doing is flip the restart-origin bit on the orders
> implicit in the group.
> 
> 
> 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
> 
> 
> _______________________________________________
> 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