[Pacemaker] Advisory ordering and "Cannot migrate"
David Vossel
dvossel at redhat.com
Wed Jun 6 14:46:59 EDT 2012
----- Original Message -----
> From: "Vladislav Bogdanov" <bubble at hoster-ok.com>
> To: pacemaker at oss.clusterlabs.org
> Sent: Friday, June 1, 2012 2:24:58 PM
> Subject: Re: [Pacemaker] Advisory ordering and "Cannot migrate"
>
> 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?
Actions that have had an advisory order constraint applied to them may or may not have the pe_action_optional flag set, those two things are not necessarily related. Please make a bug report for this so it doesn't get lost. If you can include a pe-input file that crm_simulate can run against to demonstrate this that would be great.
Just taking a quick look at the code, something like this might work.
diff --git pengine/native.c pengine/native.c
index e241063..401e817 100644
--- pengine/native.c
+++ pengine/native.c
@@ -2666,6 +2666,9 @@ at_stack_bottom(resource_t * rsc)
continue;
}
+ if (other_w->type & pe_order_optional) {
+ continue;
+ }
crm_trace("%s: Checking %s ordering", rsc->id, other->uuid);
-- Vossel
>
> 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
>
>
> _______________________________________________
> 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
>
More information about the Pacemaker
mailing list