Running two containerlab deploy/destroy commands at the same time does not end well. Vagrant is even more finicky.
That's not a big deal unless you create/destroy labs at scale, for example, in parallel integration tests using device-module-test script. You could get "netlab up" failure appear in test results and "netlab down" failures terminate the whole test suite.
Having a mutex around "netlab up"/"netlab down" steps seems like a good idea, and the easiest implementation seems to be flock /tmp/netlab.lock -c 'some command'.
As we know that netlab up/down eventually completes (or terminates or crashes), there's hope that flock won't hang forever.
Running two containerlab deploy/destroy commands at the same time does not end well. Vagrant is even more finicky.
That's not a big deal unless you create/destroy labs at scale, for example, in parallel integration tests using device-module-test script. You could get "netlab up" failure appear in test results and "netlab down" failures terminate the whole test suite.
Having a mutex around "netlab up"/"netlab down" steps seems like a good idea, and the easiest implementation seems to be
flock /tmp/netlab.lock -c 'some command'.As we know that netlab up/down eventually completes (or terminates or crashes), there's hope that flock won't hang forever.