Bug 972017 - Failed delete leaves vm_state alone but leaves task_state in "deleting"
Failed delete leaves vm_state alone but leaves task_state in "deleting"
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
2.1
Unspecified Unspecified
unspecified Severity low
: ---
: 4.0
Assigned To: Brent Eagles
Ami Jeain
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 14:43 EDT by Brent Eagles
Modified: 2015-06-04 17:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 16:18:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 957267 None None None Never

  None (edit)
Description Brent Eagles 2013-06-07 14:43:02 EDT
Description of problem:

Under some conditions, if a delete operation fails, the task_state remains as "deleting" and the vm_state in the original state. This is confusing, and at-first-glance, is not distinguishable from a "wedged in progress" type of error.

How reproducible:

Difficult/unknown. Without instrumenting the code to synthesize failure conditions, a load/stress-test environment may aide in reproducing.

Steps to Reproduce:

See https://bugzilla.redhat.com/show_bug.cgi?id=957267 for one scenario that this occurs.

Other approaches might be to initiate a delete on a instance with a remote compute node that is unavailable or with a disabled libvirt service.

Actual results:

VMs with a variety of VM_STATE values but task_state =deleting.

Expected results:

Not prescribed. Perhaps a VM_STATE that is clearly consistent with the task_state?

Additional info:

This issue should be evaluated with care to ensure that, unless there are extenuating circumstances that make it invalid to do so, subsequent attempts to delete the instance do succeed.
Comment 2 Brent Eagles 2013-09-23 16:18:25 EDT
Some of the remaining scenarios involve unavailable services upon time of deletion. Whether or not it is correct to force deletion of the database record is somewhat debatable (orphan libvirt domains, images, etc..). In any case, the fact that the VM was actually in state deleting was by design so closing as "not a bug" seems reasonable. Subsequent issues should be reported by the specific cause of the error state.

Note You need to log in before you can comment on or make changes to this bug.