Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 972017 - Failed delete leaves vm_state alone but leaves task_state in "deleting"
Summary: Failed delete leaves vm_state alone but leaves task_state in "deleting"
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 2.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.0
Assignee: Brent Eagles
QA Contact: Ami Jeain
Depends On:
TreeView+ depends on / blocked
Reported: 2013-06-07 18:43 UTC by Brent Eagles
Modified: 2019-09-09 13:34 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-23 20:18:25 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 957267 1 None None None 2021-01-20 06:05:38 UTC

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.

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