On 2013-09-13T17:48:40, Tom Parker <tpar...@cbnco.com> wrote:
> Hi Feri
>
> I agree that it should be necessary but for some reason it works well
> the way it is and everything starts in the correct order. Maybe
> someone on the dev list can explain a little bit better why this is
> working. It may have something to do with the fact that it's a clone
> instead of a primitive.
And luck. Your behaviour is "undefined", and will work for most of the
common cases.
":" versus "inf:" on the order means that, during a healthy start-up,
A will be scheduled to start before B. It does not mean that B will need
to be stopped before A. Or that B shouldn't start if A can't. Typically,
both are required.
Since you've got ordering, *normally*, B will start on a node where A is
running. However, if A can't run on a node for any given reason, B will
still try to start there without collocation. Typically, you'd want to
avoid that.
The issues with the start sequence tend to be mostly harmless - you'll
just get additional errors for failure cases that might distract you
from the real cause.
The "stop" issue can be more difficult, because it might imply that A
fails to stop because B is still active, and you'll get stop escalation
(fencing). However, it might also mean that "A" enters an escalated stop
procedure itself (like Filesystem, which will kill -9 processes that are
still active), and thus implicitly stop "B" by force. That'll probably
work, you'll see everything stopping, but it might require additional
time from "B" on next start-up to recover from the aborted state.
e.g., you can be lucky, but you also might turn out not to be. In my
experience, this means it'll all work just fine during controlled
testing, and then fail spectacularly under a production load.
Hence the recommendation to fix the constraints ;-)
(And, yes, this *does* suggest that we made a mistake in making this so
easy to misconfigure. "But, hey, ordering and colocation are independent
concepts! The design and abstraction is pure!" And I admit that I guess
I'm to blame for that to a large degree ... If the most common case is
"A, then B + B where A", why isn't there a recommended constraint that
just does both with no way of misconfiguring that? It's pretty high on
my list of things to have fixed.)
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
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
