04.04.2012 02:12, Andrew Beekhof wrote: > On Fri, Mar 30, 2012 at 7:10 PM, Florian Haas <flor...@hastexo.com> wrote: >> On Thu, Mar 29, 2012 at 8:35 AM, Andrew Beekhof <and...@beekhof.net> wrote: >>> On Thu, Mar 29, 2012 at 5:28 PM, Vladislav Bogdanov >>> <bub...@hoster-ok.com> wrote: >>>> Hi Andrew, all, >>>> >>>> Pacemaker restarts resources when resource they depend on (ordering >>>> only, no colocation) is migrated. >>>> >>>> I mean that when I do crm resource migrate lustre, I get >>>> >>>> LogActions: Migrate lustre#011(Started lustre03-left -> lustre04-left) >>>> LogActions: Restart mgs#011(Started lustre01-left) >>>> >>>> I only have one ordering constraint for these two resources: >>>> >>>> order mgs-after-lustre inf: lustre:start mgs:start >>>> >>>> This reminds me what have been with reload in a past (dependent resource >>>> restart when "lower" resource is reloaded). >>>> >>>> Shouldn't this be changed? Migration usually means that service is not >>>> interrupted... >>> >>> Is that strictly true? Always? >> >> No. Few things are always true. :) However, see below. >> >>> My understanding was although A thinks the migration happens >>> instantaneously, it is in fact more likely to be pause+migrate+resume >>> and during that time anyone trying to talk to A during that time is >>> going to be disappointed. >> >> I tend to be with Vladislav on this one. The thing that most people >> would expect from a "live migration" is that it's interruption free. >> And what allow-migrate was first implemented for (iirc), live >> migrations for Xen, does fulfill that expectation. Same thing is true >> for live migrations in libvirt/KVM, and I think anyone would expect >> essentially the same thing from checkpoint/restore migrations where >> they're available. >> >> So I guess it's reasonable to assume that if one resource migrates, >> dependent resources need not be restarted. > > Ok, could someone file a bug requesting the new behaviour please?
cl#5055 > >> But since Pacemaker now >> does restart them, you might need to figure out a way to preserve the >> existing functionality for users who rely on that. Not sure if any do, >> though. >> >> Cheers, >> Florian >> >> -- >> Need help with High Availability? >> http://www.hastexo.com/now >> >> _______________________________________________ >> Pacemaker mailing list: Pacemaker@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@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@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
