The subnet is already taken by /tmp/pytest-of-root/pytest-21/env0/lago/default/uuid

[nvgoldin]

@gbenhaim
http://jenkins.ovirt.org/job/lago_master_github_check-patch-fc25-x86_64/450/testReport/junit/tests.functional-sdk/test_sdk_sanity/test_custom_log/

I am actually seeing this locally quite often since 0c8de17 was merged. Perhaps now the code does what it was supposed to do?

I think what happened per the job that failed - init failed in a previous job, but the /tmp/.... lago environment was not destroyed and the subnet lease remained in the locks.

[nvgoldin]

Looks like we're partly affected by pytest-dev/pytest#1120
Regardless, need to think of a proper way to clean it up.

[nvgoldin]

Another failure: http://jenkins.ovirt.org/job/lago_master_github_check-patch-fc25-x86_64/451/testReport/tests.functional-sdk/test_sdk_sanity/test_custom_log/
cleaned it up manually on the slave

[gbenhaim]

In another build, I saw that the networks weren't destroyed.
Taken from the slave:

virsh # net-list
 Name                 State      Autostart     Persistent
----------------------------------------------------------
 default              active     yes           yes
 dfe5-net-01          active     no            no
 dfe5-net-02          active     no            no

[nvgoldin]

which build?

[gbenhaim]

http://jenkins.ovirt.org/job/lago_master_github_check-patch-fc25-x86_64/457/

[nvgoldin]

Looking at the slave's build history, these might be leftovers from:
http://jenkins.ovirt.org/job/lago_master_github_check-patch-fc25-x86_64/449/console

Where the job simply timed out:

17:16:40 test_sdk_sanity.py::test_extract_paths_ignore_nopath[vm-el7-3-base-/nothing/here-normal] PASSED
22:52:26 test_sdk_sanity.py::test_extract_paths_ignore_nopath[vm-el7-3-base-/nothing/here-dead] Build timed out (after 360 minutes). Marking the build as failed.
22:52:26 $ ssh-agent -k
22:52:26 unset SSH_AUTH_SOCK;

So this is a little different - the networks were still up, not only the leases. This issue is probably more rare and fixing it would mean updating the job's cleanup script.

Either way I think this (good) behaviour is new, I guess before it just re-wrote the lease or something.
Implementing #599 would probably solve most issues.