Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> writes:
> 1. 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.
