Open lukaszachy opened 2 years ago
Probably the only thing tmt should allow is 'standalone' login mode. All other attempts to use run from active workdir should be caught and denied unless user to removes the lock.
@lukaszachy, if we create a lock file for login
, the lock file would be saved as WORKDIR_ROOT/<GuestID>.lock
on host side (e.g. /var/tmp/tmt/local.lock
if local host is used as guest
for test execution), is it okay?
I'm not sure it is worth doing right now before multihost which will require a lot of changes in the flow of tmt run.
There are corner cases to solve for better UX
push
or not (I think both use cases are valid and user should be able to choose)I'm not sure it is worth doing right now before multihost which will require a lot of changes in the flow of tmt run.
OK, let's not try to fix it for the time being.
BTW,if we go back to implement this via file lock
, module fcntl could be used.
fcntl.lockf(fd, fcntl.LOCK_EX | fcntl.LOCK_NB)
in __enter__
method;fcntl.lockf(fd, fcntl.LOCK_UN)
in __exit__
method.
Not sure how much is this supported but at least for the second command to be just login it is something tempting to do (and working if timed correctly)
Reproducer
On my machine, "second" tmt command (the one which is supposed to just login) generates ssh private key and continues to login but by doing so it locks out first command which waits asking for password until timeout happens.
Probably the only thing tmt should allow is 'standalone' login mode. All other attempts to use run from active workdir should be caught and denied unless user to removes the lock.