----- Original Message ----- > From: "Vladislav Bogdanov" <[email protected]> > To: [email protected] > 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" <[email protected]> > >> To: "The Pacemaker cluster resource manager" > >> <[email protected]> > >> 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. The migration operations don't actually get calculated by the policy engine. All moves are calculated as "stop/start" internally and then at the end of all the calculations we attempt to detect when we can migrate based on the final graph. -- Vossel > 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 > > _______________________________________________ > Pacemaker mailing list: [email protected] > 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: [email protected] 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
