@Duncan:
I tried with lvmdriver-1, fails with error:
ImageCopyFailure: Failed to copy image to volume: qemu-img:
/dev/mapper/stack--volumes--lvmdriver--1-volume--e8323fc5--8ce4--4676--bbec--0a85efd866fc:
error while converting raw: Could not open device: Permission denied
It's been configured
Thanks Avishay.
In our case the middle layer (our storage appliance) doesn't allow a
snapshot to be deleted if it has clones due to an internal implementation
that tries to optimize storage by using a Dependency tree where the base
volume is the root of the tree and snapshots or clones are nodes
Sorry, I meant to say that the expected behavior is that volumes are
independent entities, and therefore you should be able to delete a snapshot
even if it has volumes created from it (just like you should be able to
delete a volume that has clones from it). The exception is that Cinder
will not
Deleting a volume created from a snapshot is permitted. Performing
operations on a volume created from snapshot should have the same behavior
as volumes created from volumes, images, or empty (no source). In all of
these cases, the volume should be deleted, regardless of where it came
from.
I thought that case should be caught well before it gets to the driver. Can
you retry with the LVM driver please?
On 27 February 2015 at 10:48, Eduard Matei eduard.ma...@cloudfounders.com
wrote:
Hi,
We've been testing our cinder driver extensively and found a strange
behavior in the UI:
-
Hi,
We've been testing our cinder driver extensively and found a strange
behavior in the UI:
- when trying to delete a snapshot that has clones (created volume from
snapshot) and error is raised in our driver which turns into
error_deleting in cinder and the UI; further actions on that snapshot
