Difference between revisions of "Glance-api-v2-image-sharing"
Line 29: | Line 29: | ||
* image sharing is fine-grained ... it is on an image-by-image basis | * image sharing is fine-grained ... it is on an image-by-image basis | ||
* image sharing occurs within a region only | * image sharing occurs within a region only | ||
+ | * no need for a concept of "trusted users"; A and B are both normal Glance users | ||
== Use Cases == | == Use Cases == | ||
Line 51: | Line 52: | ||
# 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. | # 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) | + | ==== (7) Force a user to see my images ==== |
+ | # Cannot be done. We see this as an advantage. | ||
== Pain Points == | == 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. | # 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. | ||
+ | # The API operations are very fine-grained, i.e., at the individual image level. They can be coarsened in the UI. | ||
+ | # 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. |
Revision as of 18:00, 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
- no need for a concept of "trusted users"; A and B are both normal Glance users
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) Force a user to see my images
- Cannot be done. We see this as an advantage.
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.
- The API operations are very fine-grained, i.e., at the individual image level. They can be coarsened in the UI.
- 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.