On 04/12/2012, at 9:20 AM, Lars Marowsky-Bree <l...@suse.com> wrote:
> On 2012-12-03T16:32:14, David Vossel <dvos...@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@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
_______________________________________________
Pacemaker mailing list: Pacemaker@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
