I'm mostly using our own driver, but for the logs attached I'm using the
default driver (nova.volume.driver.ISCSIDriver, I believe)
When I went back and looked at the behavior of the default driver I saw
that it's slightly different to the behavior I described in the bug report,
though it's still broken, I think.
If I create a volume, then create a snapshot from the volume, and then try
to delete the base volume, nova-volumes attempts to delete the volume, but
fails and the volume is left in the stat 'error-deleting'
In fact I can subsequently delete the snapsnot, but I can't delete the
volume.
# euca-delete-volume vol-0000009d
ApiError: Volume status must be available
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Yuriy Taraday
Sent: 14 November 2011 19:05
To: Leahy, Oliver
Subject: [Bug 888649] Re: Snapshots left in undeletable state
What volume driver do you use? Can you post nova-volume logs related to
this bug?
Bug description:
If a volume is created using the euca api, then a snapshot is created from the volume then the volume is deleted
the snapshot cannot now be deleted. If the user tries
to delete the snapshot it ends up in the state 'error_deleting'
and remains in the system.
The following sequence of euca commands illustrates the problem
$ euca-create-volume -s 1 -z nova
VOLUME vol-0000007c 1 creating (bocktest, None, None, None) 2011-11-10T17:36:41Z
# euca-create-snapshot vol-0000007c
SNAPSHOT snap-00000018 vol-0000007c creating 2011-11-10T17:37:33Z 0%
# euca-delete-volume vol-0000007c# euca-delete-volume vol-0000007c
VOLUME vol-0000007c
# euca-delete-snapshot snap-00000018
SNAPSHOT snap-00000018
# euca-describe-snapshots
SNAPSHOT snap-00000018 vol-0000007c error_deleting 2011-11-10T17:37:33Z 100%
# euca-delete-snapshot snap-00000018
Traceback (most recent call last):
File "/usr/bin/euca-delete-snapshot", line 110, in <module>
main()
File "/usr/bin/euca-delete-snapshot", line 101, in main
return_code = euca_conn.delete_snapshot(snapshot_id)
File "/usr/lib/pymodules/python2.7/boto/ec2/connection.py", line 1112, in delete_snapshot
return self.get_status('DeleteSnapshot', params)
File "/usr/lib/pymodules/python2.7/boto/connection.py", line 648, in get_status
raise self.ResponseError(response.status, response.reason, body)
boto.exception.EC2ResponseError: EC2ResponseError: 400 Bad Request
<?xml version="1.0"?>
<Response><Errors><Error><Code>ApiError</Code><Message>Snapshot status must be available</Message></Error></Errors><RequestID>286ce49b-3c6d-4dcb-8130-52afe8b9ba94</RequestID></Response>
I'm mostly using our own driver, but for the logs attached I'm using the driver. ISCSIDriver, I believe)
default driver (nova.volume.
When I went back and looked at the behavior of the default driver I saw
that it's slightly different to the behavior I described in the bug report,
though it's still broken, I think.
If I create a volume, then create a snapshot from the volume, and then try
to delete the base volume, nova-volumes attempts to delete the volume, but
fails and the volume is left in the stat 'error-deleting'
In fact I can subsequently delete the snapsnot, but I can't delete the
volume.
# euca-create-volume -s 1 -z nova 15T12:53: 25Z snapshot vol-0000009d 15T12:53: 46Z 0%
VOLUME vol-0000009d 1 creating (bocktest, None, None, None) 2011-11-
# euca-create-
SNAPSHOT snap-00000022 vol-0000009d creating 2011-11-
# euca-delete-volume vol-0000009d
VOLUME vol-0000009d
# euca-describe- volumes 15T12:53: 25Z
VOLUME vol-0000009d 1 nova error_deleting (bocktest, #########, None, None) 2011-11-
# euca-delete-volume vol-0000009d
ApiError: Volume status must be available
-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Yuriy Taraday
Sent: 14 November 2011 19:05
To: Leahy, Oliver
Subject: [Bug 888649] Re: Snapshots left in undeletable state
What volume driver do you use? Can you post nova-volume logs related to
this bug?
-- /bugs.launchpad .net/bugs/ 888649
You received this bug notification because you are subscribed to the bug
report.
https:/
Title:
Snapshots left in undeletable state
Status in OpenStack Compute (Nova):
New
Bug description:
then a snapshot is created from the volume
then the volume is deleted
If a volume is created using the euca api,
the snapshot cannot now be deleted. If the user tries
to delete the snapshot it ends up in the state 'error_deleting'
and remains in the system.
The following sequence of euca commands illustrates the problem
$ euca-create-volume -s 1 -z nova 10T17:36: 41Z snapshot vol-0000007c 10T17:37: 33Z 0% snapshot snap-00000018 snapshots 10T17:37: 33Z 100% snapshot snap-00000018 euca-delete- snapshot" , line 110, in <module> euca-delete- snapshot" , line 101, in main delete_ snapshot( snapshot_ id) pymodules/ python2. 7/boto/ ec2/connection. py", line 1112, in delete_snapshot status( 'DeleteSnapshot ', params) pymodules/ python2. 7/boto/ connection. py", line 648, in get_status ror(response. status, response.reason, body) exception. EC2ResponseErro r: EC2ResponseError: 400 Bad Request <Errors> <Error> <Code>ApiError< /Code>< Message> Snapshot status must be available< /Message> </Error> </Errors> <RequestID> 286ce49b- 3c6d-4dcb- 8130-52afe8b9ba 94</RequestID> </Response>
VOLUME vol-0000007c 1 creating (bocktest, None, None, None) 2011-11-
# euca-create-
SNAPSHOT snap-00000018 vol-0000007c creating 2011-11-
# euca-delete-volume vol-0000007c# euca-delete-volume vol-0000007c
VOLUME vol-0000007c
# euca-delete-
SNAPSHOT snap-00000018
# euca-describe-
SNAPSHOT snap-00000018 vol-0000007c error_deleting 2011-11-
# euca-delete-
Traceback (most recent call last):
File "/usr/bin/
main()
File "/usr/bin/
return_code = euca_conn.
File "/usr/lib/
return self.get_
File "/usr/lib/
raise self.ResponseEr
boto.
<?xml version="1.0"?>
<Response>
To manage notifications about this bug go to: /bugs.launchpad .net/nova/ +bug/888649/ +subscriptions
https:/