This is because the new PodmanProvisioner and its .stop() may remove "isolated" (custom subdir) storage location, which needs all containers to be (ideally) stopped and unmounted. The logic inside .stop() already does that after calling .release() for all remotes, but an external thread could interfere here.
If the thread calls .release(), it would set self.release_called = True, which would insta-complete the .stop()-called .release() even while that external threads hasn't finished releasing (running podman rm).
A with self._lock: across the whole podman rm calling section would make .stop() block and wait until the external thread finished releasing the Remote, avoiding the race.
This is because the new PodmanProvisioner and its
.stop()may remove "isolated" (custom subdir) storage location, which needs all containers to be (ideally) stopped and unmounted. The logic inside.stop()already does that after calling.release()for all remotes, but an external thread could interfere here.If the thread calls
.release(), it would setself.release_called = True, which would insta-complete the.stop()-called.release()even while that external threads hasn't finished releasing (runningpodman rm).A
with self._lock:across the wholepodman rmcalling section would make.stop()block and wait until the external thread finished releasing the Remote, avoiding the race.