The point of that delete in the test is to ensure that the copied image (in swift) is independent of the original image (in s3).
Now I think it should be OK for the deletion of the *original* image to be mediated by the glance API layer, to avoid the test being directly boto-aware.
But the fact that the subsequent GET of the copied image ID fails with a 404 indicates either:
(a) the copy isn't really independent of the existence of the original,
The point of that delete in the test is to ensure that the copied image (in swift) is independent of the original image (in s3).
Now I think it should be OK for the deletion of the *original* image to be mediated by the glance API layer, to avoid the test being directly boto-aware.
But the fact that the subsequent GET of the copied image ID fails with a 404 indicates either:
(a) the copy isn't really independent of the existence of the original,
or:
(b) swift is intermittently broken.
Evidence pointing to option (b) includes the fact that the mysterious 404 returned by swift afflicts other tests intermittently, e.g TestS3. test_remote_ image in https:/ /jenkins. openstack. org/job/ gate-glance- python26/ 85/console
I'll continue to dig tomorrow, but I suspect an intermittent swift issue may be the nub of the problem.