Willem de Bruijn willemdebruijn.kernel@gmail.com writes:
Cleaning up remote state in all conditions, including timeout/kill.
Some tests require a setup phase before the test, and a matching cleanup phase. If any of the configured state is variable (even just a randomized filepath) this needs to be communicated to the cleanup phase. The remote filepath is handled well here. But if a test needs per-test setup? Say, change MTU or an Ethtool feature. Multiple related tests may want to share a setup/cleanup.
Personally I like to wrap responsibilities of this sort in context managers, e.g. something along these lines:
class changed_mtu: def __init__(self, dev, mtu): self.dev = dev self.mtu = mtu
def __enter__(self): js = cmd(f"ip -j link show dev {self.dev}", json=True) self.orig_mtu = something_something(js) cmd(f"ip link set dev {self.dev} mtu {self.mtu}")
def __exit__(self, type, value, traceback): cmd(f"ip link set dev {self.dev} mtu {self.orig_mtu}")
with changed_mtu(swp1, 10000): # MTU is 10K here # and back to 1500
A lot of this can be made generic, where some object is given a setup / cleanup commands and just invokes those. But things like MTU, ethtool speed, sysctls and what have you that need to save a previous state and revert back to it will probably need a custom handler. Like we have them in lib.sh as well.