Indeed. It seems there is a bug in this test. The volume is created with a method that will delete the volume during tearDownClass, but the code that attaches the volume does not add a cleanup to put the volume back in a state where the delete can succeed. So when the ssh which is in between the attach and detach calls raises an exception, the volume is left in an undeletable state.
Indeed. It seems there is a bug in this test. The volume is created with a method that will delete the volume during tearDownClass, but the code that attaches the volume does not add a cleanup to put the volume back in a state where the delete can succeed. So when the ssh which is in between the attach and detach calls raises an exception, the volume is left in an undeletable state.