So the test referenced does wait for the delete, but as a part of it's tearDownClass. The test uses the common create_server call from the base test class to create the server:
So I'm not sure where the bug here is exactly. Delete will be called twice on the server once because of addCleanup and once because of clear_servers(), but that shouldn't be an issue because of clear_servers() is written to be fault tolerant.
Although looking at the test code it's probably an issue with the clear_servers() method which is designed to not hang up on an exception, we're also not logging one if we hit it. It's probably worth improving the logic in clear_servers() to log exceptions on errors, besides 404s, before moving on to the next server so we have a record that the delete failed. I don't think we want to necessarily fail here, if the delete was an important part of what was being tested it should be done explicitly in the test method.
So the test referenced does wait for the delete, but as a part of it's tearDownClass. The test uses the common create_server call from the base test class to create the server:
http:// git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ api/compute/ images/ test_images_ negative. py#n69
which appends the server to the list of servers to be tore down during tearDownClass:
http:// git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ api/compute/ base.py# n255
and
http:// git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ api/compute/ base.py# n143
So I'm not sure where the bug here is exactly. Delete will be called twice on the server once because of addCleanup and once because of clear_servers(), but that shouldn't be an issue because of clear_servers() is written to be fault tolerant.
Although looking at the test code it's probably an issue with the clear_servers() method which is designed to not hang up on an exception, we're also not logging one if we hit it. It's probably worth improving the logic in clear_servers() to log exceptions on errors, besides 404s, before moving on to the next server so we have a record that the delete failed. I don't think we want to necessarily fail here, if the delete was an important part of what was being tested it should be done explicitly in the test method.