Difference between revisions of "Glance-api-v2-image-sharing"

Revision as of 21:37, 9 January 2013

In this discussion, we'll assume 2 users:

• "A" who wants to share images
• "B" who is a user other than "A"

Background

Currently, the image list for user B contains all of the following:

1. all public images
2. all images owned by B
3. all images that have B as an image member (currently v1 only)

Currently, image owner A can add B as a member of A's image I1

Problem

The problem with using image members as a basis of full-blown image sharing is that B may not want to see I1 in the image list (i.e., the SPAM problem). So the implementation of image sharing that we want to do has two aspects: For an image G to show up in user B's list of images, it should be the case that both (a) A wants to share G, and (b) B actually wants to see G.

Proposal

Add another image property similar to image members called something like "accepted-tenants". The property would be a list of tenantIds. The only way this property can be modified is: the tenantId of the person making the call matches the tenantId being added/removed from the "accepted-tenants" list.

So now we can have two image-list calls:

1. the one described above (this would be like looking into your email SPAM folder)
2. a call that changes the third clause as follows: all images that both (a) have B as an image member and (b) have B as an element of the "accepted-tenant" list

Implications

Under this proposal:

• image sharing is completely independent of public images. Public images are only set by the cloud provider (as is the case now)
• image sharing is fine-grained ... it is on an image-by-image basis
• image sharing occurs within a region only
• no need for a concept of "trusted users"; A and B are both normal Glance users

User Stories

Here's a list of things you might want to do with an image sharing capability. For each one, we assess how it could be accomplished using the scheme outlined above.

(1) Sharing an image

1. A adds B as a member of image I1 (current Glance v1 API call)
2. Independently of Glance, A contacts B informing B of the UUID of image I1
3. B makes a call to the Glance API requesting that B be added to the "accepted-tenants" list of I1

(2) Un-sharing a previously shared image

1. A removes B as a member of image I1

(3) Removing a shared image from my image-list

1. B makes a call to the Glance API requesting that B be removed from the "accepted-tenants" list of I1

(4) Removing all images shared by user A from my image-list

1. Well, this will be a pain in the butt. You'll have to (a) take the Glance response to the (non-SPAM) image-list and (somehow) filter it to display only those images owned by A, (b) make a list of these image UUIDs, and then (c) for each image UUID, make a request to the Glance API requesting that you be removed from the "accepted-tenants" list of that image. Would best be handled by enhancing the UI.

(5) Image Discovery

1. Use the "SPAM folder" version of the image-list call

(6) View all images available to me from user A

1. Use the "SPAM folder" version of the image-list call; take the Glance response and (somehow) filter it to display only those images owned by A

(7) View all images available from user A

1. No way to do this through Glance under the current proposal. A could set up some kind of independent service, e.g., a wiki page with image UUIDs and descriptions and a form for sending your tenantId to A.

(8) Force a user to see my images

1. Cannot be done. We see this as an advantage.

Pain Points

1. Sharing is regional only; if image cloning to other regions is implemented so that a UUID is preserved across regions, this could easily be handled in the UI/API script.
2. The API operations are very fine-grained, i.e., at the individual image level. They can be coarsened in the UI.
3. Orchestration of sharing (i.e., the notification to B from A that there is stuff to be shared is completely independent of Glance. We see this as an advantage.