[Pacemaker] Advisory ordering and "Cannot migrate"

[David Vossel]

----- 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?

-- 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
>