Difference between revisions of "Glance-api-v2-image-sharing"
Line 20: | Line 20: | ||
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. | 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 | + | So now we can have '''two''' image-list calls: |
# the one described above (this would be like looking into your email SPAM folder) | # the one described above (this would be like looking into your email SPAM folder) | ||
− | # a call that changes the third clause as follows: all images that both (a) have B as an image member | + | # 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 | ||
+ | |||
+ | == Use Cases == | ||
+ | ==== (1) Sharing an image ==== | ||
+ | # A adds B as a member of image I1 | ||
+ | # Independently of Glance, A contacts B informing B of the UUID of image I1 | ||
+ | # 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 ==== | ||
+ | # A removes B as a member of image I1 | ||
+ | |||
+ | ==== (3) Removing a shared image from my image-list ==== | ||
+ | # B makes a call to the Glance API requesting that B be removed from the "accepted-tenants" list of I1 | ||
+ | |||
+ | ==== (4) Image Discovery ==== | ||
+ | # Use the "SPAM folder" version of the image-list call | ||
+ | |||
+ | ==== (5) View all images available ''to me'' from user A ==== | ||
+ | # 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 | ||
+ | |||
+ | ==== (6) View all images available from user A ==== | ||
+ | # 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. | ||
+ | |||
+ | ==== (7) ==== | ||
+ | |||
+ | == Pain Points == | ||
+ | # 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. |
Revision as of 17:42, 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:
- all public images
- all images owned by B
- 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 (SPAM).
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:
- the one described above (this would be like looking into your email SPAM folder)
- 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
Use Cases
(1) Sharing an image
- A adds B as a member of image I1
- Independently of Glance, A contacts B informing B of the UUID of image I1
- B makes a call to the Glance API requesting that B be added to the "accepted-tenants" list of I1
- A removes B as a member of image I1
- B makes a call to the Glance API requesting that B be removed from the "accepted-tenants" list of I1
(4) Image Discovery
- Use the "SPAM folder" version of the image-list call
(5) View all images available to me from user A
- 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
(6) View all images available from user A
- 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.
(7)
Pain Points
- 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.