Bug 966088 - [sanlock] Return information about the current owner(s) of a resource
[sanlock] Return information about the current owner(s) of a resource
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sanlock (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: David Teigland
Leonid Natapov
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-22 08:49 EDT by Federico Simoncelli
Modified: 2013-11-21 06:49 EST (History)
2 users (show)

See Also:
Fixed In Version: sanlock-2.8-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-21 06:49:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1632 normal SHIPPED_LIVE sanlock bug fix and enhancement update 2013-11-20 20:32:25 EST

  None (edit)
Description Federico Simoncelli 2013-05-22 08:49:00 EDT
Description of problem:
Sanlock should provide an API to gather information about the owner of a resource.

Additional info:
After speaking with David we agreed on sanlock_check_resource which should behave as:
1. if the resource is hold by the local host: return the local host id and (eventually) the process id owning the resource
2. if the resource is free: return that the resource is free (no hosts)
3. if the resource is hold by a remote host: return the remote host id if it's alive or failing, return free if the host is dead
4. if the resource is shared: mark the resource as shared and return a list of hosts holding the resource
Comment 4 Aharon Canan 2013-08-01 08:01:14 EDT
Leonid, 

please work with Federico and check how to test it/verify it.
Comment 5 Leonid Natapov 2013-08-27 08:58:00 EDT
(In reply to Aharon Canan from comment #4)
> Leonid, 
> 
> please work with Federico and check how to test it/verify it.

David,how can we test it ?
Comment 6 David Teigland 2013-08-27 11:16:58 EDT
Sorry there's no test for this "built in" to sanlock itself.

You can use the test that I use by downloading:
https://git.fedorahosted.org/cgit/sanlock.git/plain/tests/sanlk_testr.c?id=sanlock-2.8

And you'll probably need to install the sanlock-devel rpm to compile it:
gcc sanlk_testr.c -lsanlock -o sanlk_testr

Then run the following sequence of commands:

truncate -s 1G /root/leasefile
chown sanlock.sanlock /root/leasefile

sanlock client init -s L:0:/root/leasefile:0
sanlock client init -r L:R:/root/leasefile:1048576
sanlock add_lockspace -s L:1:/root/leasefile:0

sanlock client command -r L:R:/root/leasefile:1048576 -c /bin/sleep 100 &

sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
owner 1 gen 1
test_flags 1

(Correct result is test_flags 1 because resource lease is held by /bin/sleep.)

killall -9 sleep

sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
test_flags 0

(Correct result is test_flags 0 because resource lease is not held.)
Comment 7 Leonid Natapov 2013-10-02 04:44:56 EDT
sanlock-2.8-1.el6.x86_64.

tested according David's instructions:
[root@nott-vds1 tmp]# ./sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
owner 1 gen 1
test_flags 1
[root@nott-vds1 tmp]# killall -9 sleep
[1]+  Killed                  sanlock client command -r L:R:/root/leasefile:1048576 -c /bin/sleep 100
[root@nott-vds1 tmp]# 
[root@nott-vds1 tmp]# 
[root@nott-vds1 tmp]# ./sanlk_testr L:R:/root/leasefile:1048576
lockspace hosts:
host 1 gen 1 state 3
resource owners:
test_flags 0
Comment 9 errata-xmlrpc 2013-11-21 06:49:10 EST
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

Note You need to log in before you can comment on or make changes to this bug.