Hide Forgot
Description of problem: Sanlock should provide a way to request the release of a resource currently held by another host. Additional info: This feature is currently implemented in the daemon but it's not exposed through the python bindings. A patch has been posted upstream: https://lists.fedorahosted.org/pipermail/sanlock-devel/2013-May/000367.html As far as the use case is concerned this feature is probably dependent on some previous patches: 9863624 python: return lease version in read_resource 0ce413a python: add the versioning support to acquire The API call named "request" (for consistency with the name exposed by the C API) is defined as follows: request(lockspace, resource, disks [, action=REQ_RELEASE, version=0]) The possible values for action are REQ_RELEASE and REQ_FORCE (which escalates to sigkill if the regular graceful release is not satisfied).
how do we test this?
(In reply to Yaniv Eylon from comment #2) > how do we test this? Using a shared storage, two hosts and sanlock commands (even better python scripts). We'll add the technical details (e.g. sanlock commands or python scripts) ASAP.
Here is a sequence of commands to test the capability without the need for a separate test program. It uses a shared vg "test" with a shared lv "test". host1,2: service wdmd start host1,2: service sanlock start host1: lvcreate -n test -L1G test sanlock client init -s test:0:/dev/test/test:0 sanlock client init -r test:test:/dev/test/test:1048576 host1: sanlock client add_lockspace -s test:1:/dev/test/test:0 host2: sanlock client add_lockspace -s test:2:/dev/test/test:0 host1: sanlock client command -r test:test:/dev/test/test:1048576 -c /bin/sleep 1000 (This acquires the lock then runs "sleep" for 1000 seconds.) host2: sanlock client request -r test:test:/dev/test/test:1048576:2 -f 1 (After this, the "sleep" on host1 should be killed within 30 seconds.)
sanlock-2.8-1.el6.x86_64. tested according to instructions in comment #4.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1632.html