[Pacemaker] Advisory ordering on clones not working?

[Andrew Beekhof]

On Tue, Feb 21, 2012 at 3:12 PM, Vladislav Bogdanov
<bubble at hoster-ok.com> wrote:
> 21.02.2012 02:40, Andrew Beekhof wrote:
>> On Mon, Feb 20, 2012 at 11:49 PM, Vladislav Bogdanov
>> <bubble at hoster-ok.com> wrote:
>>> 20.02.2012 14:36, Andrew Beekhof wrote:
>>>> On Mon, Feb 20, 2012 at 10:26 PM, Adrian Fita <adrian.fita at gmail.com> wrote:
>>>>> Thanks, I figured it out by now. But the real problem I'm facing is
>>>>> explained in http://oss.clusterlabs.org/pipermail/pacemaker/2012-February/013124.html
>>>>> . Please also take a look there. This advisory thing was me trying to
>>>>> solve the problem described in that message.
>>>>
>>>> Ok, I see that thread.  I'll get to that one soon.
>>>
>>> I now look at the similar case (advisory ordering doesn't work).
>>>
>>> I hope I can add some pointers on what exactly happens.
>>>
>>> Imagine you have two advisory-ordered resources each also depend
>>> (colocated and mandatory ordered) on some other resource (f.e.
>>> filesystem on drbd device Master state).
>>> I now play with lustre filesystem. It consists of several parts:
>>> * MGS (one per cluster, cluster can consist of several lustre filesystems)
>>> * MDT (one per filesystem)
>>> * OST (many per filesystem)
>>> It is very important for lustre to operate properly that MDT is started
>>> after MGS and OSTs started after MDT.
>>
>> The you must not use advisory constraints for this sequence.
>
> Heh, but then I will be unable to move filesystem parts between drbd
> replicas for failover... Advisory ordering allows me to move MGS or MDT
> to another replica without restarting all the OSTs.
>
> Need to think again about making them migratable...
>
>>
>>>
>>> In my case I have MDT configured to start after MGS (advisory) and each
>>> OST to start after MDT. Each of lustre parts is resided on a drbd device
>>> (stacked one, so there is one more drbd device under it).
>>>
>>> What I see after transition from stop-all-resources="true" to "false" is
>>> that some OSTs (which are located on nodes different from where MDT is)
>>> are started before MDT. I see that advisory ordering is not honored when
>>> dependencies of "then" resource are satisfied before ones of "first"
>>> resource.
>>
>> So /both/ sides of the constraint are starting or stopping but the PE
>> isn't enforcing the ordering?
>
> At one moment LogActions prints that they all are about to start.
> Then deps for two "then" resources are satisfied and they are actually
> started while "first" resource is not.

Ok, can you file a bug for that please?  I'll get David to have a look.