Jump to: navigation, search

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

Line 50: Line 50:
 
* no need for a concept of "trusted users"; A and B are both normal Glance users
 
* no need for a concept of "trusted users"; A and B are both normal Glance users
  
== User Stories ==
+
== Use Cases ==
  
 
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.
 
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.
Line 100: Line 100:
 
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.
 
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:
+
How: ''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., A's webpage, and you would have to notify A independently of Glance that you would like access to the image.''
 
 
# 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., A's webpage, and you would have to notify A independently of Glance that you would like access to the image.
 
  
 
Note: We do not see this as a disadvantage.
 
Note: We do not see this as a disadvantage.
Line 110: Line 108:
 
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).
 
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:
+
How: ''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.''
 
 
# 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.
 
  
 
Note: We do not see this as a disadvantage.
 
Note: We do not see this as a disadvantage.
Line 119: Line 115:
 
What: I have created some fantastic images that are so good that I want user B to see them in B's image-list, whether or not B is really interested in them, because the images are so good that I know once B sees them, B will want to continue to see them.
 
What: I have created some fantastic images that are so good that I want user B to see them in B's image-list, whether or not B is really interested in them, because the images are so good that I know once B sees them, B will want to continue to see them.
  
How:
+
How: ''Cannot be done.''
# Cannot be done.
+
 
 +
Note: We see this as an advantage ... after all, it's the whole point of this proposal!
 +
 
 +
==== (10) 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.''
 +
 
 +
==== (11) Automatically see new images from a specific user ====
 +
What: B likes A's images and would like to "accept" all sharing requests from A without having to make an API call to accept a new image from A.
 +
 
 +
How: ''Can't be done in Glance since Glance does not directly track user-to-user relations''
 +
 
 +
Note: This could be done in the UI or via some kind of system job (see the discussion of 1-many sharing, below).
  
Note: We see this as an advantage ... this is the whole point of this proposal!
+
==== (12) Image sharing inheritance ====
 +
What: User A has shared image I1 with user B (and B has accepted). For some reason (e.g., security update), user A wants to withdraw image I1 and replace it with image I8, and image I8 should show up in user B's image-list in the place of image I1.
  
==== () Never see any images from a specific user ("banned list") ====
+
How: ''Can't be done in Glance under the current proposal.''
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 GlanceWould have to be done by the normal spam control measures of whatever notification service is used.
+
Note: There's no way for Glance to know that I8 is a "replacement" for I1.  Not sure that we want to implement it, either, because allowing A to unilaterally swap shared images would allow the old bait-and-switchThis is really a matter for the cloud provider to decide, could be handled in the UI or via some kind of system job (see the discussion of 1-many sharing, below).
  
==== () 1-1 image sharing ====
+
==== (13) 1-1 image sharing ====
 
What: A wants to share image I1 with B.
 
What: A wants to share image I1 with B.
  
 
How:
 
How:
# This is simply user story (1), above.
+
# This is simply user story (1), above. (Just wanted to be excruciatingly explicit about this use case!)
  
==== () 1-many image sharing ====
+
==== (14) 1-many image sharing ====
 
What: A wants to share image I1 with users {B, C, D, ..., Z} (e.g., suppose that A is an IT dude for company SMB, and {B, C, D, ..., Z} are all employees of SMB, and A prefers all employees to use I1 instead of some similar public image)
 
What: A wants to share image I1 with users {B, C, D, ..., Z} (e.g., suppose that A is an IT dude for company SMB, and {B, C, D, ..., Z} are all employees of SMB, and A prefers all employees to use I1 instead of some similar public image)
  

Revision as of 17:08, 14 January 2013


#!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

Use Cases

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: 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., A's webpage, and you would have to notify A independently of Glance that you would like access to the image.

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: 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.

Note: We do not see this as a disadvantage.

(9) Force a user to see my images

What: I have created some fantastic images that are so good that I want user B to see them in B's image-list, whether or not B is really interested in them, because the images are so good that I know once B sees them, B will want to continue to see them.

How: Cannot be done.

Note: We see this as an advantage ... after all, it's the whole point of this proposal!

(10) 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.

(11) Automatically see new images from a specific user

What: B likes A's images and would like to "accept" all sharing requests from A without having to make an API call to accept a new image from A.

How: Can't be done in Glance since Glance does not directly track user-to-user relations

Note: This could be done in the UI or via some kind of system job (see the discussion of 1-many sharing, below).

(12) Image sharing inheritance

What: User A has shared image I1 with user B (and B has accepted). For some reason (e.g., security update), user A wants to withdraw image I1 and replace it with image I8, and image I8 should show up in user B's image-list in the place of image I1.

How: Can't be done in Glance under the current proposal.

Note: There's no way for Glance to know that I8 is a "replacement" for I1. Not sure that we want to implement it, either, because allowing A to unilaterally swap shared images would allow the old bait-and-switch. This is really a matter for the cloud provider to decide, could be handled in the UI or via some kind of system job (see the discussion of 1-many sharing, below).

(13) 1-1 image sharing

What: A wants to share image I1 with B.

How:

  1. This is simply user story (1), above. (Just wanted to be excruciatingly explicit about this use case!)

(14) 1-many image sharing

What: A wants to share image I1 with users {B, C, D, ..., Z} (e.g., suppose that A is an IT dude for company SMB, and {B, C, D, ..., Z} are all employees of SMB, and A prefers all employees to use I1 instead of some similar public image)

How:

  • For user U-sub-i in {B, C, D, ..., Z}:
    1. A adds U-sub-i as a member of image I1
    2. Independently of Glance, A contacts U-sub-i informing U-sub-i of the UUID of image I1
    3. U-sub-i makes a call to the Glance API requesting that U-sub-i's status on image I1 be changed to 'accepted'

Note: This requires the individual users to take an action, which is not what A wants; A wants I1 available for immediate use by fellow employees. In other words, this is user story (9), above. Our position is that it is not Glance's business to distinguish between "trusted" users like this IT dude and "normal" users who simply want to share some images. Rather, this distinction must be made at the cloud provider level. So here's another approach:

How:

  1. Independently of Glance, A is recognized by the cloud provider as a "trusted" user.
  2. For user U-sub-i in {B, C, D, ..., Z}: A adds U-sub-i as a member of image I1 (and I2, etc.)
  3. Independently of Glance, the cloud provider runs a system job (with admin credentials), say every 30 minutes, that goes through A's image-list and for each image-member whose status is 'null', marks the image as 'accepted'

Note: This would still allow individual employees to reject the image, which seems OK to us, since they would have to make a conscious decision to reject the image, and if so, then they really don't want to see it. But the cloud provider could modify the system job to handle this case and mark the image as 'accepted'; this all depends on the relation between A and the cloud provider and is not a Glance concern. The key point is that a kind of fascist 1-many image sharing is possible under this proposal.

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.