Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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. In contrast, colocation bar_on_foo inf: bar foo means that 1. bar is to run wherever foo runs (_that_ part you can consider semantically identical); 2. if bar is not started, foo will of course run; 3. if bar fails and cannot recover, foo will continue to run. 4. if foo is not started, then bar won't run at all; 5. if foo fails and cannot recover, then bar will shut down. 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. Hope this helps. Florian -- Need High Availability training? http://www.hastexo.com/services/custom-training