Hi, On Wed, Jun 02, 2010 at 02:40:15PM +0100, Maros Timko wrote: > >> Hi all, > >> > >> I just came across following scenario: > >> - using resource group DRBD - Delay - Xen > >> - resources are active on node A that should become active > >> - Start CRM > >> - CRM probes resources, detects Delay as Stopped > >> - CRM wants to start it, because of dependancy meaning Stop VM, Start > >> Delay, Start VM > >> > >> I think restart of VM is not needed, it is caused due to fact that > >> Delay RA is not stateful. Would you agree if it is modified to become > >> stateful? If yes, I could supply a patch. > > > > > > If you have to resort to use the "Delay" resource agent, > > that almost always means there is a bug somewhere else, > > either in some resource agent, or interaction, or > > in the configuration concept or dependencies. > > > > Please don't mask bugs. > > My apologies, I hurried a bit. > I checked the details now and can confirm that OCF Delay RA _is_ > stateful. The thing that happened to me was caused by fact that > Heartbeat cleans up $RSC_TMPDIR on every start.
Heartbeat shouldn't do that anymore. The consensus was to have the temporary directory moved to /var/run which is going to be cleaned up by the OS on boot. Thanks, Dejan > This directory is used > for state information handling by default. So it was my configuration > failure because I relied on it. > > However, it uncovered that behavior of such resources could differ > whether or not CRM uses Heartbeat or AIS. At least looking at > Pacemaker code (1.0.7), I only found creation of this directory but no > clean up. I would not say it is a bug though, just a Heartbeat legacy > that users should be aware of. > > Thanks, > Tino > > > > > -- > > : Lars Ellenberg > > : LINBIT | Your Way to High Availability > > : DRBD/HA support and consulting http://www.linbit.com > > > > DRBD? and LINBIT? are registered trademarks of LINBIT, Austria. > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
