On Mon, Oct 5, 2020 at 1:45 PM Benny Zlotnik <bzlotnik(a)redhat.com> wrote:
This patch tests writing and reading to LVB via python bindings.
Signed-off-by: Benny Zlotnik <bzlotnik(a)redhat.com>
---
tests/python_test.py | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/tests/python_test.py b/tests/python_test.py
index abd459e..6316790 100644
--- a/tests/python_test.py
+++ b/tests/python_test.py
@@ -764,3 +764,26 @@ def test_acquire_path_length(no_sanlock_daemon):
path = "x" * (constants.SANLK_PATH_LEN - 1)
with raises_sanlock_errno():
sanlock.acquire(b"ls_name", b"res_name", [(path, 0)],
pid=os.getpid())
+
+def test_lvb(tmpdir, sanlock_daemon):
+ ls_path = str(tmpdir.join("ls_name"))
+ util.create_file(ls_path, MiB)
+
+ res_path = str(tmpdir.join("res_name"))
+ util.create_file(res_path, MiB)
+
+ sanlock.write_lockspace(b"ls_name", ls_path, offset=0, iotimeout=1)
+ sanlock.add_lockspace(b"ls_name", 1, ls_path, offset=0, iotimeout=1)
+
+ disks = [(res_path, 0)]
+ sanlock.write_resource(b"ls_name", b"res_name", disks)
+
+ fd = sanlock.register()
+
+ sanlock.acquire(b"ls_name", b"res_name", disks, slkfd=fd,
lvb=True)
+ sanlock.set_lvb(b"ls_name", b"res_name", disks,
b"{gen:0}")
Accessing lvm works only when the resource is acquired?
+ result = sanlock.get_lvb(b"ls_name",
b"res_name", disks)
+ sanlock.release(b"ls_name", b"res_name", disks, slkfd=fd)
+
+ assert result == "{gen:0}"
Nice test, but it shows that get_lvb is *decoding* the data on output,
which is wrong. The API should accept and return the same type.
In the current form, if I try to set_lvb() with unicode value encoded
in another encoding, like:
>> "\u05d0".encode("cp1255")
b'\xe0'
When reading the python bindings will try to decode using "utf-8"
and:
>> b'\xe0'.decode("utf-8")
Traceback
(most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe0 in position
0: unexpected end of data
The issue is probably using the wrong format string when
building the return value.
Other issues that should be tested:
- Handling of too long input - the input should not be truncated silently but
but fail the call.
- Handling of null bytes in the lvm block - is this supported by sanlock or
it treats lvm as a null terminated string?
I did not have time yet to review the other patches. The user facing API
makes sense except the decoding issue.
Nir