Open Stack

Hey Gorka,
    Thanks for your input:) I think I need to clarify that our idea is to
share the backup resource to another tenants, that is different with
transfer as the original tenant still can fully control the backup
resource, and the tenants that have been shared to only have the ability to
see and read the content of that backup.

Gorka Eguileor <geguileo at redhat.com>于2018年3月21日周三 下午7:15写道：

> 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.
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180321/7e82e80f/attachment.html>