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-06-21 13:51:03

17) This issue was raised by AndrewBeekhof. He may need one or two new operations on ResourceInstances - but he hasn't decided. They are

  • flush - throw away all items queued for this resource, and return them as cancelled.
  • drain - wait for all items queued for this resource to complete, then do nothing. This is a queued no-op.
  • A related question: Does the failure of an operation automatically invoke a flush of the jobs in the queue?

    HuangZhen said, flush: flush has been add to the new version of lrm_api.h, please refer to Issue 16. drain: would you like to explain why we need drain? the question: according to current design, there is no automatic flush.

    • for example, if "start" operation failed, maybe client want to use an "stop" to shutdown it or use an "status" to see what status it is now.

    AlanRobertson replies: This is exactly why an automatic flush of existing, but not executed operations might be desirable. The problem is that you only return the status of the last command, and also the next commands on the operation might not be appropriate if an operation in the queue failed first. This is the kind of thing that disk device drivers and others that queue commands do. But, no one has decided whether this should happen. This is really just a comment at this point, sort of a reminder that we need to make a decision on what the right thing to do is.

    AlanRobertson continues on about drain(). This is another type of operation which is common when command queueing is present. The purpose of a drain operation is that one might want to know when all existing operations on a particular resource are completed. The drain operation completes when all the operations in the queue (regardless of how many there are and where the came from) complete. As was mentioned before, this is not something which had been decided is a requirement. It's a reminder to Andrew to decide for sure, and then if he says yes, we can go ahead and do it. It would probably be important that the drain operation not change the last command executed or last command return code.

    LarsMarowskyBree adds that an automatic flush() on failure seems to be desirable. It is not mandatory though. A drain() however seems not to be needed, given that we have get_cur_state() and flush(). But it sure wouldn't hurt either, we may just not end up using it. It remains to be defined if a drain() would also cancel any pending monitor operations (as flush() likely should too)? My gut feeling is that it should.

    AlanRobertson clarifies some more. A drain() operation can only be approximated by a status operation. However, it is not a perfect approximation, since it clears the last operation state. The point of a drain operation is not error recovery but determination of status, so IMHO, it should not meddle with anything else like cancel current monitor operations (like a flush would). Another way to add a drain which might be more useful would be to add an immediate/queued parameter to the get_cur_state() operation. Given that we aren't actually doing anything much to our resources, IMHO many of the other traditional operations like suspend and resuming queues, and giving immediate (unqueued) operations would be overkill here.

    AndrewBeekhof chips in. I'm thinking that neither drain() nor flush() should cancel the monitor op. As I see it, the intention of both functions is to (help) determin the most up-to-date information for a resource - stopping the monitor op goes against this purpose (or at least the purpose I had in mind). However I can see that if any action fails, it would be nice if the monitor stopped so it doesnt overwrite the last action & result information.

    AndrewBeekhof rambles on... as for drain() vs. flush(), I think having flush() and a get_cur_state() that had an immediate/queued parameter would do very nicely thankyou :)