Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Friday 07 October 2011 13:26:19 Florian Haas wrote: > On 2011-10-07 10:00, Arnold Krille wrote: > > On Friday 07 October 2011 09:50:47 Felix Frank wrote: > >> On 10/07/2011 09:41 AM, Arnold Krille wrote: > >>> The order on a colocation doesn't matter. > >> > >> funny you should mention "order" in this context. You do in fact want to > >> add an order constraint for these resources. > > > > I know, but some people didn't want to believe me and said that the order > > of elements inside the colocation was of any importance. > > I'll make one more attempt at explaining. If your opinion is set and you > prefer not to be confused with facts, don't read on. > > colocation foo_on_bar inf: foo bar > > means that > 1. foo is to run wherever bar runs; > 2. if bar is not started, then foo won't run at all; > 3. if bar fails and cannot recover, then foo will shut down; > 4. if foo is not started, bar will of course run; > 5. if foo fails and cannot recover, bar will continue to run. > <snip> > > To make the point again with a sledge hammer, of the five (5) aspects > with which a colocation affects resource management, one (1) is > identical irrespective of the order in which the resources are listed in > the colocation definition. The other four (4) are not. I think I am beginning to understand what you mean. Altough I didn't come to this understanding from the docs I read so far. I will test this in the next days. Some questions: - If the rule is not inf: but something like 100:, what happens when (in your first example that I quoted above) bar fails and can not recover? A colocation- binding with a score of less then inf would leave a chance for foo to run without bar or (if other scores are right) to run on a different node than bar, right? - Your (2) would mean that foo is actually started after bar finished starting? Otherwise foo wouldn't know if bar didn't start. Have a nice weekend, Arnold -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111007/274e9dee/attachment.pgp>