[Image] failed to reach ACTIVE status within the required time (196 s). Current status: SAVING
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceilometer |
Invalid
|
Undecided
|
Unassigned | ||
OpenStack Compute (nova) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
http://
The relevant part of the test case:
1. Boot servet1
2. Boot server2 wait until active
3. wait until server1 ACTIVE
4. Create snapshot from server1, wait until ACTIVE with 196 sec timeout
5. Cleanup, die with the first failure
Normally the test case would create 2 additional image at the beginning,
but now died at fist image creation.
2014-05-09 21:44:09.857 | Captured traceback:
2014-05-09 21:44:09.858 | ~~~~~~~~~~~~~~~~~~~
2014-05-09 21:44:09.858 | Traceback (most recent call last):
2014-05-09 21:44:09.858 | File "tempest/
2014-05-09 21:44:09.858 | cls.server1['id'], wait_until=
2014-05-09 21:44:09.858 | File "tempest/
2014-05-09 21:44:09.858 | kwargs[
2014-05-09 21:44:09.858 | File "tempest/
2014-05-09 21:44:09.858 | waiters.
2014-05-09 21:44:09.858 | File "tempest/
2014-05-09 21:44:09.858 | raise exceptions.
2014-05-09 21:44:09.859 | TimeoutException: Request timed out
2014-05-09 21:44:09.859 | Details: (ListImageFilte
message:"failed to reach ACTIVE status within the required time" AND filename:
description: | updated |
description: | updated |
summary: |
- failed to reach ACTIVE status within the required time (196 s). Current - status: SAVING + [Image] failed to reach ACTIVE status within the required time (196 s). + Current status: SAVING |
tags: | added: testing |
Changed in nova: | |
status: | Incomplete → Invalid |
We could have a ton of these various timeout issues in Tempest, we're never going to nail these down properly so we need to step back and start looking at Tempest and thinking about how to make that smarter than assuming a hard-coded value is going to fit all scenarios, i.e. there could be concurrent load on the host causing it to run slow at the time of failure, or we could look at getting diagnostic information back about the instance and logging that to see if there is something more specific to fingerprint when we hit a timeout failure.