This site best when viewed with a modern standards-compliant browser. We recommend Firefox Get Firefox!.

Linux-HA project logo
Providing Open Source High-Availability Software for Linux and other OSes since 1999.

USA Flag UK Flag

Japanese Flag

Homepage

About Us

Contact Us

Legal Info

How To Contribute

Security Issues

This web page is no longer maintained. Information presented here exists only to avoid breaking historical links.
The Project stays maintained, and lives on: see the Linux-HA Reference Documentation.
To get rid of this notice, you may want to browse the old wiki instead.

1 February 2010 Hearbeat 3.0.2 released see the Release Notes

18 January 2009 Pacemaker 1.0.7 released see the Release Notes

16 November 2009 LINBIT new Heartbeat Steward see the Announcement

Last site update:
2018-01-16 12:50:54

19) Clarification of flush command behavior.

SunJiangDong asks: A flush command to a RA is received while the last operation of the same RA is not finished yet. How to deal with this situation? flush at once or flush until the last operation is finished? Now the choice is: execute "flush" operation until the last operation is finished.

  • AndrewBeekhof points out that since the LocalResourceManager is single threaded, this should not be an issue as (with the exception of monitor()) it will have always finished the current action before it gets the flush operation. If other asynchronous operations (from the point-of-view of the LocalResourceManager) are added, we should readdress this issue at that time.

    AlanRobertson begs to both disagree and clarify. Although the LocalResourceManager is not threaded, it can have many operations going on at once in child processes for different ResourceInstances, and several queued for a given ResourceInstance. From the point of view of the user interface to the LocalResourceManager, almost all operations are asynchronous. So, the question is not moot. However, there are probably only two operations which can be safely interrupted. Those are status and monitor. All other interruptions risk damaging the integrity of the resource. Therefore the LRM should either not interrupt any operations at all, or only interrupt status and monitor operations.

    AlanRobertson also suggests that other issues get separate issue files, so we can move this one to closed status, if there are no disagreements. The other cases where we had several sub-issues came out as a result of the flow of the discussion, not by intention from the beginning.

    AndrewBeekhof, while possibly choosing a sub-optimal way to express it, agrees with AlanRobertson that the LRM should either not interrupt any operations at all, or only interrupt status and monitor operations.