An interesting new exception chain to interpret
Closed this issue · 9 comments
# stratis pool
Traceback (most recent call last):
File "/home/tasleson/projects/stratis/dbus-python-client-gen/src/dbus_python_client_gen/_invokers.py", line 319, in dbus_func
return dbus_method(*xformed_args, timeout=timeout)
File "/usr/lib64/python3.6/site-packages/dbus/proxies.py", line 145, in __call__
**keywords)
File "/usr/lib64/python3.6/site-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: no total physical size computed for pool with uuid 3b8e5c85-a0d8-4b04-ab5e-826689e7d020
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/tasleson/projects/stratis/stratis-cli/src/stratis_cli/_main.py", line 48, in the_func
result.func(result)
File "/home/tasleson/projects/stratis/stratis-cli/src/stratis_cli/_actions/_top.py", line 68, in list_pools
managed_objects = ObjectManager.Methods.GetManagedObjects(proxy, {})
File "/home/tasleson/projects/stratis/dbus-python-client-gen/src/dbus_python_client_gen/_invokers.py", line 327, in dbus_func
name, xformed_args)) from err
dbus_python_client_gen._errors.DPClientInvocationError: Error while invoking method "GetManagedObjects" belonging to interface "org.freedesktop.DBus.ObjectManager" with arguments ()
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/tasleson/projects/stratis/stratis-cli/bin/stratis", line 33, in <module>
main()
File "/home/tasleson/projects/stratis/stratis-cli/bin/stratis", line 29, in main
return run()(sys.argv[1:])
File "/home/tasleson/projects/stratis/stratis-cli/src/stratis_cli/_main.py", line 52, in the_func
raise StratisCliActionError(command_line_args, result) from err
stratis_cli._errors.StratisCliActionError: Action selected by command-line arguments ['--propagate', 'pool'] which were parsed to Namespace(func=<function TopActions.list_pools at 0x7fb4e364e6a8>, propagate=True) failed
The last exception in the chain is: org.freedesktop.DBus.Error.Failed. This is caused by a call to GetManagedObjects which in turn invoked a method to get a property, specifically get_pool_total_physical_used. This method called total_physical_used on the pool, and this ultimately returned an error. This error was thrown away and another error was substituted in get_total_physical_used. But the type of the error, org.freedesktop.Dbus.Error.Failed is necessary.
The description of the error is "A generic error; "something went wrong" - see the error message for more. " which is not that exciting or useful.
It may be that there is nothing much more useful that we can do than what is available. However, there is access to the method called, obviously GetManagedObjects. We could argue that method failure and GetManagedObjects call argues a failure to get a property. Of course, it would be better if we could eliminate all these possible failures, which is the real plan.
This might still be worth doing, but it would be a bit more compex, since it would require looking at two items in the chain to get any sort of definite information.
The summary message would be something like:
Most likely one of your pools is in a state where some information about it can not be obtained.
I think it's much better to fix that problem, by altering how the properties are obtained for GetManagedObjects.
Note that examining the middle exception in the chain will require making dbus-python-client-gen v0.7 available, as the same exception raised has no information in dbus-python-client-gen v0.6.
Another real life link, in testing: https://bugzilla.redhat.com/show_bug.cgi?id=1687002.
Since v2.0.0 it is vastly less likely that GetManagedObjects() will return an error; it should be impossible. So, let's not worry about matching this error.