search

stratis-storage / stratisd

Easy to use local storage management for Linux.
https://stratis-storage.github.io
Mozilla Public License 2.0
797 stars 55 forks source link

Tidy up udev tests #3542

Closed mulkieran closed 9 months ago

mulkieran commented 9 months ago

It's trivial if the tests run to completion.

mulkieran commented 9 months ago

The first commit is enough to cause the f39 tests not to time out anymore, but the failure on the generic test comes back there and the f38 test is still timing out.

======================================================================
ERROR: test_generic (tests.udev.test_udev.UdevTest1.test_generic)
See _test_driver for description.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/dbus_python_client_gen/_invokers.py", line 344, in dbus_func
    return dbus_method(*xformed_args, signature=signature, timeout=timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/dbus/connection.py", line 634, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/var/ARTIFACTS/work-alll1x3gpmu/plans/all/discover/default-0/tests/tests/client-dbus/tests/udev/test_udev.py", line 131, in test_generic
    self._test_driver(2, 4)
  File "/var/ARTIFACTS/work-alll1x3gpmu/plans/all/discover/default-0/tests/tests/client-dbus/tests/udev/test_udev.py", line 122, in _test_driver
    self.wait_for_pools(number_of_pools)
  File "/var/ARTIFACTS/work-alll1x3gpmu/plans/all/discover/default-0/tests/tests/client-dbus/tests/udev/_utils.py", line 462, in wait_for_pools
    known_pools = get_pools(name=name)
                  ^^^^^^^^^^^^^^^^^^^^
  File "/var/ARTIFACTS/work-alll1x3gpmu/plans/all/discover/default-0/tests/tests/client-dbus/tests/udev/_utils.py", line 115, in get_pools
    managed_objects = ObjectManager.Methods.GetManagedObjects(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/dbus_python_client_gen/_invokers.py", line 351, in dbus_func
    raise DPClientInvocationError(
dbus_python_client_gen._errors.DPClientInvocationError: Error while invoking method "GetManagedObjects" belonging to interface "org.freedesktop.DBus.ObjectManager" with arguments ()

----------------------------------------------------------------------
Ran 12 tests in 845.668s

FAILED (errors=1)
make: *** [Makefile:28: udev-tests] Error 1
mulkieran commented 9 months ago

Besides using stop_pool we just need to start the pool when we bring up stratisd again. I think that is a fair test in most cases. I think, though, that enhancing stratis-dumpmetadata to overwrite pool metadata would be exactly what we need here to make a more correct test.

Related: https://github.com/stratis-storage/project/issues/683 .

mulkieran commented 9 months ago

Something has just gone wrong w/ our loop tests on every platform:

test: TANG_URL=localhost RUST_LOG=stratisd=debug STRATISD=/usr/libexec/stratisd STRATIS_DUMPMETADATA=/usr/bin/stratis-dumpmetadata PYTHONPATH=./src make -f Makefile tang-tests dump-metadata-tests

All seem to be yielding clevis errors with three indicating that cryptsetup is not found. All of this should be quite orthogonal to any changes here.

mulkieran commented 9 months ago

Waiting for resolution of #3543