rackspace/reddwarf — pull request #235 by TimSimpsonR (2011-10-13 16:11:36+00:00)
Title: This pull request fixes issues in the REST API and the tests

I'm not sure why these tests aren't failing every single time, some of the issues I saw on my machine were pretty severe.
I'll just copy and paste from my commits to make it easier:

* Added code to the infamous test to make certain the failure notifications are logged when the subclassed compute manager attempts to clean things up. This asserts that the clean up code actually runs.
* Added a time_out to the delete_instance method of the VerifyManagerAbortsInstanceWhenGuestInstallFails test.
* There was some test code which overcomes a "feature" recently added to Nova by changing the states of the database from within a test. This means the tests passed but a user won't be able to duplicate the success unless they too have access to the database. :p I moved this work-around into the Reddwarf REST API code.
* The call to suspend in the initialize_volume method of ReddwarfInstanceInitializer seemed to fail occasionally, because the compute driver would object to suspending an instance which did not exist. I personally feel the compute manager should be more flexible than that, but for now changed the code to change the database state to suspend and do nothing since at the point in the subclassed compute manager the call has not been made to start the instance.
* Cleaned up the tests which seemed to exhibit problems in my Vagrant environment.
* Some tests methods used the @test decorator but were in classes extending unittest.TestCase. That's a problem, so I removed the method decorators. I don't think this usually fails when all the tests are run but it caused problems when I was running groups in isolation.
& Changed the REST API delete call to change the instance state from ERROR or SUSPENDED to ACTIVE so the underlying Compute API will delete it. This was absolutely the cause of an error in the scheduler test and my mind is 100% blown this issue isn't affecting everyone. That test creates an instance with a huge amount of memory, expecting it to be failed. It is, and is set to an error state. The test then deletes the instance... which was failing before. So again I have no idea why this isn't messing up everyone's test runs.