[Pacemaker] Advisory ordering and "Cannot migrate"

[Vladislav Bogdanov]

29.05.2012 18:51, David Vossel wrote:
> ----- Original Message -----
>> From: "Vladislav Bogdanov" <bubble at hoster-ok.com>
>> To: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
>> Sent: Tuesday, May 29, 2012 7:27:12 AM
>> Subject: [Pacemaker] Advisory ordering and "Cannot migrate"
>>
>> Hi Andrew, David, all,
>>
>> It seems that advisory ordering is honored when pengine wants to move
>> two advisory-ordered resources in one transition, and one of
>> resources
>> (then) is migrateable.
>>
>> I have advisory ordering configured for two resources, "mgs" and
>> "drbd-testfs-stacked":
>>
>> order drbd-testfs-stacked-after-mgs 0: mgs:start
>> drbd-testfs-stacked:start
>>
>> "mgs" is ordinary resource, "drbd-testfs-stacked" is migrateable.
>>
>> If both that resources are located on one node, and I request
>> shutdown
>> of that node, I see:
>> pengine[2069]:   notice: check_stack_element: Cannot migrate
>> drbd-testfs-stacked due to dependency on mgs (order)
>>
>> From what I understand, symmetrical advisory ordering should affect
>> resources which are about to be both started or both stopped in one
>> transition. That's fine.
>>
>> But, should it be honored when one resource is to be moved with
>> start/stop while another is to be migrated?
> 
> I would expect the constraint to be honored.  What else could we possibly do that would make sense?
> 
> If you have the following symmetrical order constraint,
> 
> start A then start B
> stop B then stop A
> 
> , where B can be migrated but A can not. I would expect B to be
> stopped before A is allowed to stop regardless if B has be ability to be
> migrated or not. If both A and B were to be moved to a different node,
> and B was migrated instead of stop/started, that would invalidate both
> sides of the order constraint.

That is absolutely valid, but for _mandatory_ ordering, isn't it?

For _advisory_ one that would be
If you're about to start A and B at the same time, then start A first.
Otherwise skip this constraint. Do the same in the opposite direction
for 'stop'.

At the other hand, migration is a very special operation I'd say. It is
not a stop on one node and start on another one, but a magical move of
resource. It was running on one node and oops, it runs on another. It
does neither stop nor start, does not allocate or free resources. It
just appears in a different place.
Most common example of resource migration is live VM migration.
And last part of migration (actual switch to another node) is done
almost atomically nowadays. VM just appears on a different node.

Another example of a "real life" migration (not in clusters) would be
remote desktop, where you start application on a remote server being at
work, then you come home, connect to that desktop and see your
application. You do not stop and do not start it. You just see that your
window is "migrated" to another place.

For pacemaker this could be illustrated with some resource agent which
manages some external entity which exists "somewhere". And "resource is
running on node A" just means that that entity is managed from node A.
It does not run there, it is just managed from there. In my case that
entity is a pacemaker ticket. It exists everywhere in the cluster, but
is granted or revoked by a script (resource agent) running on one node.
I do not want that ticket to be ever touched without my explicit
command. I just allow to migrate the management point.

So, from my PoV, term "migration" does not assume any start or stop
operations. And advisory ordering (which applies to simultaneous start
or stop of two different resources) should not be honored because only
one resource is actually starting/stopping. Do I miss something here?

Best,
Vladislav