On 12/04/12 06:20, Lars Marowsky-Bree 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. ;-)
>
> "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 <y...@suse.com>
Software Engineer
China Server Team, SUSE.
_______________________________________________
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
