Open Stack

On 20/03, Jay S Bryant wrote:
>
>
> On 3/19/2018 10:55 PM, TommyLike Hu wrote:
> > Now Cinder can transfer volume (with or without snapshots) to different
> > projects,  and this make it possbile to transfer data across tenant via
> > volume or image. Recently we had a conversation with our customer from
> > Germany, they mentioned they are more pleased if we can support transfer
> > data accross tenant via backup not image or volume, and these below are
> > some of their concerns:
> >
> > 1. There is a use case that they would like to deploy their
> > develop/test/product systems in the same region but within different
> > tenants, so they have the requirment to share/transfer data across
> > tenants.
> >
> > 2. Users are more willing to use backups to secure/store their volume
> > data since backup feature is more advanced in product openstack version
> > (incremental backups/periodic backups/etc.).
> >
> > 3. Volume transfer is not a valid option as it's in AZ and it's a
> > complicated process if we would like to share the data to multiple
> > projects (keep copy in all the tenants).
> >
> > 4. Most of the users would like to use image for bootable volume only
> > and share volume data via image means the users have to maintain lots of
> > image copies when volume backup changed as well as the whole system
> > needs to differentiate bootable images and none bootable images, most
> > important, we can not restore volume data via image now.
> >
> > 5. The easiest way for this seems to support sharing backup to different
> > projects, the owner project have the full authority while shared
> > projects only can view/read the backups.
> >
> > 6. AWS has the similar concept, share snapshot. We can share it by
> > modify the snapshot's create volume permissions [1].
> >
> > Looking forward to any like or dislike or suggestion on this idea
> > accroding to my feature proposal experience:)
> >
> >
> > Thanks
> > TommyLike
> >
> >
> > [1]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Tommy,
>
> As discussed at the PTG, this still sounds like improper usage of Backup. 
> Happy to hear input from others but I am having trouble getting my head
> around it.
>
> The idea of sharing a snapshot, as you mention AWS supports sounds like it
> could be a more sensible approach.  Why are you not proposing that?
>
> Jay
>

Hi,

I agree with Jay that this sounds like an improper use of Backups, and I
believe that this feature, just like trying to transfer snapshots, would
incur in a lot of code changes as well as an ever greater number of
bugs, because the ownership structure in Cinder is hierarchical and well
defined.

So if you transferred a snapshot then you would lose that snapshot
information on the source volume, which means that we could not prevent
a volume deletion with a snapshot, or we could prevent it but would
either have to prevent the deletion from happening (creating a terrible
user experience since the user can't delete the volume now because
somebody else still has one of its snapshots) or we have to implement
some kind of "trash" mechanism to postpone cleanup until all the
snapshots have been deleted, which would make our quota code more
complex as well as make our stats reporting and scheduling diverge from
what the user think has actually happened (they deleted a bunch of
volumes but the data has not been freed from the backend).

As for backups, you have an even worse situation because of our
incremental backups, since transferring ownership of an incremental
backup will create similar deletion issues as the snapshots but we also
require access to all all incremental snapshots to restore a volume.  So
the only alternative would be to only allow transferring a full Backup
and this would carry all the incremental backups with it.

All in all I think this would be an abuse of the Backups, and as stated
by TommyLike we already have mechanisms to do this via images and volume
transfers.

Although I have to admit that after giving this some thought there is a
very good case where it wouldn't be an abuse and where we should allow
transferring full backups together with all their incremental backups,
and that is when you transfer a volume.  If we transfer a volume with
all its snapshots, it makes sense that we should also allow transferring
its backups, after all the original source of the backups no longer
belongs to the owner of the backups.

To summarize, if we are talking about transferring only full backups
with all their dependent incremental backup then I probably won't oppose
the change.

Cheers,
Gorka.