Bug 1131192

+++ This bug was initially created as a clone of Bug #1111210 +++

Description of problem:

sanlock.get_hosts cannot be used with a host_id parameter, because asking for host_id=1 returns the info for host_id=2.

[root@voodoo2 nsoffer]# python
Python 2.6.6 (r266:84292, Nov 21 2013, 10:50:32) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sanlock
>>> sanlock.get_hosts('01b7eb33-e2eb-43bf-a3dd-0f0f09023dc5')
[{'generation': 25, 'host_id': 1, 'flags': 3, 'io_timeout': 10, 'timestamp': 852460}, {'generation': 27, 'host_id': 2, 'flags': 3, 'io_timeout': 10, 'timestamp': 854412}]
>>> sanlock.get_hosts('01b7eb33-e2eb-43bf-a3dd-0f0f09023dc5', 1)
[{'generation': 27, 'host_id': 2, 'flags': 3, 'io_timeout': 10, 'timestamp': 854432}]
>>> sanlock.get_hosts('01b7eb33-e2eb-43bf-a3dd-0f0f09023dc5', 2)
[{'generation': 1, 'host_id': 3, 'flags': 2, 'io_timeout': 10, 'timestamp': 0}]

You cannot workaround this by using host_id=id-1, since when getting host_id=1, the id will become 0, which is used by the bindings as default value meaning give me the list of all hosts:

>>> sanlock.get_hosts('01b7eb33-e2eb-43bf-a3dd-0f0f09023dc5', 0)
[{'generation': 25, 'host_id': 1, 'flags': 3, 'io_timeout': 10, 'timestamp': 852871}, {'generation': 27, 'host_id': 2, 'flags': 3, 'io_timeout': 10, 'timestamp': 854843}]

Version-Release number of selected component (if applicable):
sanlock-2.8-1.el6.x86_64

How reproducible:
Always

Additional info:
Broken also on Fedora using sanlock-2.8-1.fc19.x86_64.

--- Additional comment from RHEL Product and Program Management on 2014-06-19 09:34:06 EDT ---

Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Nir Soffer on 2014-06-19 11:43:25 EDT ---



--- Additional comment from David Teigland on 2014-06-19 11:44:21 EDT ---

Nir, where do you need this fix applied and released?

--- Additional comment from Nir Soffer on 2014-06-19 12:07:46 EDT ---

I need it for ovirt-3.5, which must run on RHEL-6.5.

--- Additional comment from Nir Soffer on 2014-08-05 18:05:55 EDT ---

David, this is fixed upstream:
https://git.fedorahosted.org/cgit/sanlock.git/commit/?id=2e5150be0ad662f218a5442bd1c40f12c825022d

We need this trivial fix for ovirt-3.5, which run on EL 6.5 and Fedora 19 and 20.

--- Additional comment from David Teigland on 2014-08-06 12:12:02 EDT ---

f19: http://koji.fedoraproject.org/koji/buildinfo?buildID=551025
f20: http://koji.fedoraproject.org/koji/buildinfo?buildID=551029

I'll attempt a rhel6.5 build once there's a bz I can use.

--- Additional comment from Steve Almy on 2014-08-06 12:17:25 EDT ---

(In reply to David Teigland from comment #6)
> f19: http://koji.fedoraproject.org/koji/buildinfo?buildID=551025
> f20: http://koji.fedoraproject.org/koji/buildinfo?buildID=551029
> 
> I'll attempt a rhel6.5 build once there's a bz I can use.

Hi David,

The RHEL workflow requires that you fix the BZ in 6.6 first (via this BZ) and then it will get requested for 6.5.z.

Adding some more flags to ease the next steps.

Thanks,
Steve

--- Additional comment from David Teigland on 2014-08-06 12:23:59 EDT ---

Nir, what sanlock version will you want in rhel6.6?  A rebase to pending version 3.2.0 (which is going into rhel7.1)?  Or just selected fixes like this one?

--- Additional comment from Nir Soffer on 2014-08-06 12:36:48 EDT ---

(In reply to David Teigland from comment #8)
> Nir, what sanlock version will you want in rhel6.6?  A rebase to pending
> version 3.2.0 (which is going into rhel7.1)?  Or just selected fixes like
> this one?

I don't know about any other issue effecting rhev-3.5 other then this bug, so I will be happy with a backport of this trivial fix.

If there are any other important bug fixes I guess they should also be backported. But I would like to depend on stable version.

--- Additional comment from David Teigland on 2014-08-06 12:53:19 EDT ---

OK, just this patch then for 6.6 and 6.5.z.

--- Additional comment from Jan Kurik on 2014-08-17 04:15:26 EDT ---

May I have a status update on this bug, please ?
There is a waiting zstream request which is currently blocked by missing qa_ack.

--- Additional comment from Aharon Canan on 2014-08-17 05:31:16 EDT ---

I can't give QA ACK for RHEL issues as  I am responsible QA for RHEV storage

--- Additional comment from Allon Mureinik on 2014-08-17 08:31:29 EDT ---

Sean, who can qa-ack this? We really need to move forwards with this.

--- Additional comment from David Teigland on 2014-08-18 11:42:41 EDT ---

In the past, I believe that RHEV QA has verified sanlock bugs by either exercising the relevant part of RHEV that had a problem, or when that's not possible, I have sometimes provided direct sanlock commands that can be run to demonstrate the correct behavior.

In this case I can't provide a sanlock command to do this directly because there is no option to select a single host id (it always prints all).  Perhaps the python api could be used to do this, though?