Glance-api-v2-image-sharing

#!wiki caution
'''Under Revision'''

We're currently rewriting this document; the basic idea is the same, but some implementation ideas are changing (e.g., we're changing the "accepted-tenants" list to a (nillable) state property of each image member).

#!wiki gray/solid
== Quick Summary ==
We are proposing:
 1. porting image members to v2
 1. adding a state associated with an image member to v2
 1. adding some additional filters to the image-list call

<<TableOfContents()>>

Background

In this discussion, we'll assume 2 users:

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

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

What: A wants image I1 to appear in B's image-list.

How:

1. A adds B as a member of image I1
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's status on image I1 be changed to 'accepted'

(2) Un-sharing a previously shared image

What: A no longer wants I1 to appear in B's image-list.

How:

1. A removes B as a member of image I1

Note: There is no way for B to prevent this from occurring.

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

What: B no longer wants I1 to appear in B's image-list

How:

1. B makes a call to the Glance API requesting that B's status on image I1 be changed to 'rejected'.

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

What: B wants no images owned by A to appear in B's image-list.

How:

1. B makes an image-list request with the filters: "images-of-which-i-am-a-member" AND "owned-by A"
2. For each image UUID in the response, B makes a request to the Glance API requesting that B's status on that image be changed to 'rejected'

(5) Image Discovery of images available to me

What: B wants to know what images are available to B (i.e., the owner has shared them with B, but they are not in B's image-list).

How:

1. B makes an image-list call with the filters: "images-of-which-i-am-a-member" AND "my-membership-status-is-not-accepted"

(6) Image Discovery of shared images owned by a particular user

What: View all images available to me from user A that don't currently appear in my image-list.

How:

1. B makes an image-list request with the filters: "images-of-which-i-am-a-member" AND "owned-by A" AND "my-membership-status-is-not-accepted"

(7) Image Discovery of images owned by a particular user

What: View all images owned-by user A (even those of which I am not an image member) that don't currently appear in my image-list.

How:

1. No way to do this through Glance under the current proposal.

Note: We do not see this as a disadvantage.

(8) General Image Discovery

What: I want to know what images exist "out there" that I don't currently know about (i.e., I want to see a list of images that aren't public AND of which I am NOT an image-member).

How:

1. No way to do this through Glance under the current proposal. You would have to become aware of these via some other notification mechanism, e.g., someone's webpage or something, and you would have to notify the image owner independently of Glance that you would like access to the image.

() Force a user to see my images

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

() Never see any images from a specific user ("banned list")

What: B is sick of getting notifications about images that A would like to share, B does not want to receive any notifications about image sharing from A.

How: Can't be done in Glance since the A-to-B notifications occur independently of Glance. Would have to be done by the normal spam control measures of whatever notification service is used.

() 1-1 image sharing

1. The use

Pain Points

1. This proposal requires porting the (unliked) image members implementation from glance v1.
2. 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.
3. The API operations are very fine-grained, i.e., at the individual image level. They can be coarsened in the UI.
4. 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.
5. When image members are ported to v2, have to make sure it's the case that if B doesn't own image G, B can only build a server from G if B is a member of G.