Bug 972017

Summary: Failed delete leaves vm_state alone but leaves task_state in "deleting"
Product: Red Hat OpenStack Reporter: Brent Eagles <beagles>
Component: openstack-novaAssignee: Brent Eagles <beagles>
Status: CLOSED NOTABUG QA Contact: Ami Jeain <ajeain>
Severity: low Docs Contact:
Priority: unspecified    
Version: 2.1CC: dallan, dyocum, jkt, ndipanov, yeylon
Target Milestone: ---   
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 20:18:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Brent Eagles 2013-06-07 18:43:02 UTC 
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 20:18:25 UTC 
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.