On 2012-12-05T15:52:43, David Vossel <dvos...@redhat.com> wrote:
> Yeah, I suppose you are right. I wouldn't have thought of these two options
> as being related, but we need that inverse constraint to force the restart of
> A. Utilizing the inverse order constraint internally makes the
> implementation of this option much cleaner than it would be otherwise.
Nice, thanks.
> I have no idea why someone would want to do this... but what would happen
> with the following.
>
> start A then promote B restart-origin=true
>
> would A get restarted when B is demoted... or when B fails/stops?
The latter. (Or at least that's what I'd expect.)
But, like you say, "I have no idea why someone would want to do this".
At least in this use case, I have real trouble seeing a m/s resource as
the child resource.
I can see that coming up later (if you really go ahead with container
resources that are also managed). Maybe we should postpone the
discussion and just disallow that for now? ;-)
> I see. Mapping the failcount of one resource to another resource seems like
> it would be difficult for us to represent in the configuration without using
> some sort of container group like object where the parent resource inherited
> failures from the children.
Right. So let's skip that. It was an idea, but like Yan Gao wrote, it's
adequately handled by the migration-threshold of the "child" resource
already, if an admin really wants that behaviour.
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
