FYI: the next version of pacemaker now supports
<rsc_order id="dbreplica_before_core-101" first="dbreplica"
then="core-101" kind="Serialize" />
By specifying kind="Serialize", it tells the PE not to inhibit
migration or cause restarts.
My goal for today is to also allow one to configure:
<rsc_order id="serialize-xen" kind="Serialize">
<resource_set id="order-1-set-1">
<resource_ref id="db"/>
<resource_ref id="dbreplica"/>
<resource_ref id="core-101"/>
<resource_ref id="core200"/>
<resource_ref id="sysadmin"/>
<resource_ref id="edge"/>
<resource_ref id="base"/>
</resource_set>
</rsc_order>
And have the PE serialize any actions that are occurring within that set.
So if only db and core-101 are moving, then we'll just serialize those two.
On Wed, Dec 16, 2009 at 10:10 PM, Andrew Beekhof <[email protected]> wrote:
> On Fri, Dec 11, 2009 at 11:28 AM, Andrew Beekhof <[email protected]> wrote:
>> On Fri, Dec 11, 2009 at 2:17 AM, infernix <[email protected]> wrote:
>>> Are these location constraints conflicting with the order constraints? I
>>> mean, the cluster shouldn't care where they [start|migrate_to], as long as
>>> they [start|migrate_to] in order, one at a time (or, if possible, a
>>> configurable number of parallel jobs).
>>>
>>> I have a hb_report attached for this last case.
>>
>> I'll have a look
>>
>
> So these are the ordering constraints:
>
> db -> dbreplica
> dbreplica -> core-101
> core-101 -> core-200
> core-200 -> sysadmin
> sysadmin -> edge
> edge -> base
>
> The problem is that dbreplica and sysadmin aren't moving, so the
> ordering rules they're part of have no effect.
> The only ones doing anything in this case are: core-101 -> core-200,
> and edge -> base.
> But that still means that db, core-101, and edge can all still migrate
> at the same time.
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
