[Pacemaker] Advisory ordering and "Cannot migrate"

[Vladislav Bogdanov]

01.06.2012 20:15, David Vossel wrote:
> ----- Original Message -----
>> From: "Vladislav Bogdanov" <bubble at hoster-ok.com>
>> To: pacemaker at oss.clusterlabs.org
>> Sent: Tuesday, May 29, 2012 11:26:35 PM
>> Subject: Re: [Pacemaker] Advisory ordering and "Cannot migrate"
>>
>> 30.05.2012 01:37, David Vossel wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Vladislav Bogdanov" <bubble at hoster-ok.com>
>>>> To: pacemaker at oss.clusterlabs.org
>>>> Sent: Tuesday, May 29, 2012 3:48:12 PM
>>>> Subject: Re: [Pacemaker] Advisory ordering and "Cannot migrate"
>>>>
>>>> 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'.
>>>
>>> Yeah I missed the advisory part of this.
>>>
>>> I bet this suffers from the same implementation complications that
>>> http://bugs.clusterlabs.org/show_bug.cgi?id=5055 has. This will
>>> likely
>>> resolve itself once 5055 gets fixed... or we might be able to make
>>> a
>>> temporary targeted fix for this before then.
>>
>> That would be great.
>> From what I see in code, all oreder-related actions for migration are
>> added at the end of MigrateRsc() with comments why that is done:
>> /* migrate 'then' action also needs anything that the stop needed to
>> have completed too */
> 
> Perhaps, but I'm not sure we can determine accurately why the
> actions required before the stop are there. How can we distinguish the advisory
> order constraint's results after it has already been applied?

Ughm... Actually I do not yet fully get how all that constraints magic
works and do not yet know all the internals :(
What I see is:
All actions that would be needed to be completed in order to stop
resource being migrated are ordered before migration unless they are
marked as optional.
The same is for action that would be needed to start that resource which
we are about to migrate.
If we can look a bit deeper into that actions and determine score they
are declared with, that would make it possible to just skip all
advisory-ordered actions (like if they have pe_action_optional flag
set). Actually - we do not either start or stop resource, we _migrate_
it, thus we can skip all advisory-ordered constraints for start and
stop, while leaving all mandatory ones in place.
Is this acceptable?

Vladislav

> 
> -- Vossel
> 
>> /* migrate 'then' action also needs anything that the start needed to
>> have completed too */
>>
>> May be that function is a good place too do that?
>>
>> Vladislav
>>
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org