test: Record pool driver used for spawn_lxd when LXD_BACKEND=random for container_recover

[tomponline]

Rather than use the previous value which may be different.

Previously:

2026-02-05T10:35:09.7929548Z ==> TEST BEGIN: container_recover on random
2026-02-05T10:35:09.7930134Z ++ date +%s.%2N
2026-02-05T10:35:09.7941491Z + START_TIME=1770287709.79
2026-02-05T10:35:09.7941872Z + readonly START_TIME
2026-02-05T10:35:09.7942235Z + test_container_recover
2026-02-05T10:35:09.7943146Z + local poolDriver
2026-02-05T10:35:09.7949759Z ++ storage_backend /tmp/lxd-test.tmp.45Qe/NuR
2026-02-05T10:35:09.7950216Z ++ echo lvm
2026-02-05T10:35:09.7954456Z + poolDriver=lvm # <- poolDriver for test was set to LVM
2026-02-05T10:35:09.7954791Z + '[' lvm = pure ']'
2026-02-05T10:35:09.7955124Z + local LXD_IMPORT_DIR
2026-02-05T10:35:09.7961604Z ++ mktemp -d -p /tmp/lxd-test.tmp.45Qe XXX
2026-02-05T10:35:09.7972621Z + LXD_IMPORT_DIR=/tmp/lxd-test.tmp.45Qe/o9w
2026-02-05T10:35:09.7973207Z + spawn_lxd /tmp/lxd-test.tmp.45Qe/o9w true
2026-02-05T10:35:09.8029691Z ==> Setting up btrfs backend in /tmp/lxd-test.tmp.45Qe/o9w # <- but `spawn_lxd` chose to use btrfs
2026-02-05T10:35:09.8030378Z ==> Spawning lxd in /tmp/lxd-test.tmp.45Qe/o9w

So poolDriver=lvm but Setting up btrfs backend in /tmp/lxd-test.tmp.45Qe/o9w is the problem.

This should fix the intermittent failures in container_recover:

rmdir: failed to remove '/tmp/lxd-test.tmp.45Qe/o9w/storage-pools/lxdtest-o9w/containers/test_c1': Directory not empty failures when LXD_BACKEND=random

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

[simondeziel]

This fixes a problem I introduced in commit f280bd3

[simondeziel]

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

Now that the Code job picks the fast driver, it could definitely pick a random one.

[simondeziel]

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

Thinking some more, wouldn't that be equivalent to just duplicate a run from another driver?

[tomponline]

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

Thinking some more, wouldn't that be equivalent to just duplicate a run from another driver?

Hrm yes possibly, im not sure really what the intention is for the random storage mode.
Possibly its for inter-driver storage operations tests, but in that case, it feels we should still have a primary random storage driver selected for the run, and then also allow separate pools/lxds to be spawned with a random driver that is different from the primary one.

[simondeziel]

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

Thinking some more, wouldn't that be equivalent to just duplicate a run from another driver?

Hrm yes possibly, im not sure really what the intention is for the random storage mode.

When LXD_BACKEND=random, every invocation of spawn_lxd will get a different driver (from the available list). So the intention was to introduce variations during a given test run.

Possibly its for inter-driver storage operations tests, but in that case, it feels we should still have a primary random storage driver selected for the run, and then also allow separate pools/lxds to be spawned with a random driver that is different from the primary one.

For pool to pool transfers, I've only seen test/suites/storage_local_volume_handling.sh which cycles between all the available combinations already.

[tomponline]

Really I'd prefer to see the test suite pick a random driver at start up and use that throughout.

Thinking some more, wouldn't that be equivalent to just duplicate a run from another driver?

Hrm yes possibly, im not sure really what the intention is for the random storage mode.

When LXD_BACKEND=random, every invocation of spawn_lxd will get a different driver (from the available list). So the intention was to introduce variations during a given test run.

Possibly its for inter-driver storage operations tests, but in that case, it feels we should still have a primary random storage driver selected for the run, and then also allow separate pools/lxds to be spawned with a random driver that is different from the primary one.

For pool to pool transfers, I've only seen test/suites/storage_local_volume_handling.sh which cycles between all the available combinations already.

Lets leave as-is then, thanks!