Instance backup dir isn't deleted if instance is deleted during confirming resize
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
wangpan |
Bug Description
Reproduce steps with latest master branch of nova(but I believe grizzly, folsom also have this bug, and this occurs on our folsom stable product env):
1.hack the nova-compute code as follow:
diff --git a/nova/
index e1302bf..5a82f0b 100755
--- a/nova/
+++ b/nova/
@@ -2399,7 +2399,7 @@ class ComputeManager(
-
+ LOG.debug(
+ time.sleep(60) # sleep here and wait for the instance to be deleted
with self._error_
# NOTE(danms): delete stashed migration information
2. create an instance under devstack env
3. resize it
4. confirm the resize operation
5. delete the confirming instance when you saw the hacked log message 'sleep 60s now'
6. then the instance will be deleted and the instance backup dir 'ddb764e6-
the error log is:
2013-07-18 03:19:14.714 DEBUG nova.compute.
2013-07-18 03:19:14.717 DEBUG nova.openstack.
2013-07-18 03:19:14.718 DEBUG nova.openstack.
2013-07-18 03:19:14.718 DEBUG nova.openstack.
2013-07-18 03:19:14.751 ERROR nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
2013-07-18 03:19:14.751 TRACE nova.openstack.
description: | updated |
description: | updated |
Changed in nova: | |
assignee: | nobody → wangpan (hzwangpan) |
Changed in nova: | |
milestone: | none → havana-rc1 |
Changed in nova: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | havana-rc1 → 2013.2 |
if this bug occurs, the network rules on the source host will not be clean, too.
self. unplug_ vifs(instance, network_info)
self. firewall_ driver. unfilter_ instance( instance, network_info)
because the clean up operation in _cleanup_resize() is not run: