deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dies Koper (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DTACLOUD-441) api tests don't clean up after themselves
Date Thu, 31 Jan 2013 00:59:13 GMT

    [ https://issues.apache.org/jira/browse/DTACLOUD-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567191#comment-13567191
] 

Dies Koper commented on DTACLOUD-441:
-------------------------------------

Thanks Ronny, I found your comments in the mailing list.

M>  I guess we don't have a choice (my concern is simply the time taken to run these tests)

I feel the same: if I could find another way I would go for that.
But note that with this patch the execution time on other providers should not (or hardly)
be affected.
I believe it took 44 sec. on mock on my machine, 15 min. on fgcp. The alternative is the status
quo, no testing on fgcp :(

R>  - Running rake test:deltacloud against the first 'real' provider I tried, Vsphere,
failed out at line:
"res = get(INSTANCES+"/"+@@my_instance_id)" as @@my_instance_id returned nil (coming from
: @@my_instance_id = (res.xml/'instance')[0][:id])

That's a bummer. And I don't know how to fix that without more details or a way to test it
myself. Could you investigate? What is the response from VSphere?
Also, I can't understand how other tests (like 'should allow to snapshot running instance
if supported by provider') could work if @@my_instance_id returned nil.
Can you confirm this is really related to this patch?

R> Openstack did die on (test_0012_should allow to snapshot running instance if supported
by provider) but unlikely related to this change

Glad to hear that :) I suppose this is because of DTACLOUD-442, and by fixing this test we
now have a test case for it :)

R>  - Examining the state transitions it seems like, in general,  <start> PENDING
-> RUNNING/STOPPED <stop> STOPPING -> STOPPED. I'm not sure that all the providers
we verify against use the same terms - thought maybe one used  "STARTED" but I'm still looking
for which one :). There's always the occasional PAUSED and NEW states.

I did check the define_instance_states methods defined in all providers but didn't know about
those non-standard terms. Maybe they should be fixed in the provider (at least for NEW)?
But I can always add them to the patch. Shall I add them now or as you encounter them?

R>  - I hear the concern Marios raised about performance

For the providers you're currently running the tests with, it would add one GET /instances/instance_id
to the whole test class if the response to create has state RUNNING/STOPPING, one per instance
creation if it returns PENDING.
For fgcp, it's the fastest way I could find :(

R> - I'm not super crazy about the provider-specific comments in instances_test.rb as in:
"233     #(this also prevents failures with fgcp where the ongoing creation

I added this so that if anyone working on those other 26 providers thinks they can refactor
this out or optimise it, they'll know for which provider they're most likely to break things,
so hopefully test on fgcp early or consult with me.
I can take it out if that is not appreciated.

R> In place of driver specific comments, maybe we can switch on the driver and only execute
the "wait_until_running_or_stopped(res, created_instance_id)" if the driver in the config.yaml
has the switch to do so. This would minimize the performance concerns and still allow fgcp
a robust path through the tests.

I believe there should be no performance impact to other providers and if you notice any big
impact, I'd like to try to refactor the patch first.
Note that the first thing I do in "wait_until_running_or_stopped(res, ...)" is to check the
response returned earlier from the POST operation, so for providers like mock that transition
to RUNNING/STOPPED immediately (i.e. don't need a wait), it returns immediately, without making
any http calls.
                
> api tests don't clean up after themselves
> -----------------------------------------
>
>                 Key: DTACLOUD-441
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-441
>             Project: DeltaCloud
>          Issue Type: Test
>          Components: Server
>         Environment: Fgcp driver
>            Reporter: Dies Koper
>            Assignee: Ronelle Landy
>            Priority: Minor
>         Attachments: [PATCH] DTACLOUD441-442.eml
>
>
> When running DC api tests (rake tests:deltacloud in root tests folder), the following
is logged at the end (when using with Fgcp):
> CLEANING UP... resources for deletion: {:firewalls=>[], :instances=>["UZXC0GRT-ZG8ZJCJ07-S-0113"],
:keys=>[], :images=>[]}
> CLEANUP attempt finished... resources looks like: {:instances=>["UZXC0GRT-ZG8ZJCJ07-S-0113"]}
> deltacloud/instances_test.rb:71: Unable to delete all created resources - please check:
{:instances=>["UZXC0GRT-ZG8ZJCJ07-S-0113"]} (Ex
> ception)
>         from deltacloud/instances_test.rb:244:in `call'
>         from deltacloud/instances_test.rb:244:in `to_proc'
>         from D:/programs/Ruby187/lib/ruby/gems/1.8/gems/minitest-4.4.0/lib/minitest/unit.rb:782:in
`reverse_each'
>         from D:/programs/Ruby187/lib/ruby/gems/1.8/gems/minitest-4.4.0/lib/minitest/unit.rb:782:in
`autorun'
> The reason it failed to delete them is because it only tried to stop them, not destroy
them. For Fgcp, stopping an instance doesn't destroy it.
> Suggesting to add code that calls the destroy_instance operation on instances after the
stop operation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message