openstack team mailing list archive

[Avishay Traeger <AVISHAY@xxxxxxxxxx>]

Chuck Thier <cthier@xxxxxxxxx> wrote on 12/11/2012 21:25:32:
> Top posting to give some general history and some thoughts.
>
> Snapshots, as implemented currently in cinder, are derived from the
> EBS definition of a snapshot.  This is more of a consistent block
> level backup of a volume.  New volumes can be created from any given
> snapshot.  This is *not* usually what a snapshot is in a traditional
> storage system, though snapshots are usually used in the process.
>
> My concern with trying to expose more general snapshot, cloning, etc
> functionalities in the api is that they are very backend dependent,
> and will have different capabilities and properties.  Trying to define
> a generic API for these cases that works across all backends is going
> to be problematic, which is why I've always been supportive of having
> these implemented as extensions specific to each backend.

Hey Chuck,
Thanks for your input.  I agree with you that features that are specific to
one/few back-ends should not be in the general API.  Also, implementation
details should be left to drivers (e.g., if snapshots are full copies, CoW,
etc.).  However, I think there are some snapshot features that all
back-ends support that will give OpenStack users a better experience.  One
big one is read-only access to snapshots.  I don't think a back-end exists
that takes snapshots but doesn't allow reading from it. :)
In terms of clones, I guess (John, correct me if I'm wrong) a clone gives
you a new volume (with all its capabilities) which is a copy of the
original.  Back-ends that can do this operation efficiently can do so,
while others can simply create a new volume and copy the data.
I think that the important thing is to keep the API limited to features
that are important and that all back-ends can implement, but not specify
how they should be implemented.

Thanks,
Avishay