At present we have two problems:
- This testing is run only on the tests in our testing repo and only on the stratisd tests in that repo: https://github.com/stratis-storage/testing. This leads to the usual problem of testing which is that only what is covered is tested. Ideally, it would also be run in our other test infrastructures, in situations where it can reasonably be run.
- The test script depends on dbus-python and there is a proven bugginess in how the dbus-python infra picks up certain signals. There are I guess a few other defects, here are the issues for them.
It may be difficult to hunt down the cause of at least #741 . The strangest thing is that if the script is run in a separate terminal it catches all the signals, but if run via a subprocess call from the test infrastructure, it does not catch all the signals. This puts the problem into the area of a Glib/Python problem, since likely it has something to with the main loop and the callback mechanism and how it operates under the subprocess invocation context.
We also have one good thing, we recently switched to zbus and zbus seems to support monitoring: https://docs.rs/zbus/latest/zbus/connection/struct.Connection.html#monitoring-all-messages .
We should consider reimplementing the signal monitoring part of our test infrastructure using the zbus crate rather than dbus-python. We may want to consider running the signal monitoring infrastructure as a daemon that receives some kind of instructions, rather than as a script that receives a kill signal. The instructions might be something like:
- Take snap and begin monitoring and recording updates.
- Stop monitoring, take second snap, and diff the two snaps.
At present we have two problems:
It may be difficult to hunt down the cause of at least #741 . The strangest thing is that if the script is run in a separate terminal it catches all the signals, but if run via a subprocess call from the test infrastructure, it does not catch all the signals. This puts the problem into the area of a Glib/Python problem, since likely it has something to with the main loop and the callback mechanism and how it operates under the subprocess invocation context.
We also have one good thing, we recently switched to zbus and zbus seems to support monitoring: https://docs.rs/zbus/latest/zbus/connection/struct.Connection.html#monitoring-all-messages .
We should consider reimplementing the signal monitoring part of our test infrastructure using the zbus crate rather than dbus-python. We may want to consider running the signal monitoring infrastructure as a daemon that receives some kind of instructions, rather than as a script that receives a kill signal. The instructions might be something like: