Difference between revisions of "Glance-v2-community-image-sharing"
m |
m |
||
| Line 6: | Line 6: | ||
# An open source project wants to make a prepared VM image available so that in order to use the project's software, all you have to do is boot an instance from their image and away you go. They are too busy writing software to worry about the hassle of maintaining a list of "customers" as they'd have to do with current v2 image sharing. At the same time, the cloud provider doesn't want to make this image public, as that would imply a support relation that doesn't exist between image consumers and the cloud provider. | # An open source project wants to make a prepared VM image available so that in order to use the project's software, all you have to do is boot an instance from their image and away you go. They are too busy writing software to worry about the hassle of maintaining a list of "customers" as they'd have to do with current v2 image sharing. At the same time, the cloud provider doesn't want to make this image public, as that would imply a support relation that doesn't exist between image consumers and the cloud provider. | ||
| + | |||
| + | === Why "Community" ? === | ||
| + | |||
| + | See the use case above. Stuart brought up a case where someone could use this type of sharing to make an image available that, e.g., requires some kind of key to unlock the software on it. So the term "community" for such an image would be misleading. (Stuart suggests "broadcast".) | ||
| + | |||
| + | Personally, I think "community" is the worst term for this type of sharing ... except for all the others! But maybe someone will come up with something better. | ||
=== Constraints === | === Constraints === | ||
| Line 26: | Line 32: | ||
POST /v2/images/{image_id}/community | POST /v2/images/{image_id}/community | ||
| + | |||
DELETE /v2/images/{image_id}/community | DELETE /v2/images/{image_id}/community | ||
| Line 31: | Line 38: | ||
POST /v2/images/{image_id}/members | POST /v2/images/{image_id}/members | ||
| + | |||
request body: { "member": "*" } | request body: { "member": "*" } | ||
Revision as of 21:23, 20 February 2014
This is the full specification for the blueprint: https://blueprints.launchpad.net/glance/+spec/community-level-v2-image-sharing
This proposal adds the ability for users to initiate one-to-all sharing of an image. We call such an image a "community" image.
Contents
Use Cases
- An open source project wants to make a prepared VM image available so that in order to use the project's software, all you have to do is boot an instance from their image and away you go. They are too busy writing software to worry about the hassle of maintaining a list of "customers" as they'd have to do with current v2 image sharing. At the same time, the cloud provider doesn't want to make this image public, as that would imply a support relation that doesn't exist between image consumers and the cloud provider.
Why "Community" ?
See the use case above. Stuart brought up a case where someone could use this type of sharing to make an image available that, e.g., requires some kind of key to unlock the software on it. So the term "community" for such an image would be misleading. (Stuart suggests "broadcast".)
Personally, I think "community" is the worst term for this type of sharing ... except for all the others! But maybe someone will come up with something better.
Constraints
This proposal respects the anti-spam provisions of Images v2 image sharing. Thus, when an image owner makes the image a "community" image, any other tenant should be able to boot an instance from the image, but the image will not show up in any tenant's default image-list.
Image discovery
To preserve symmetry with Images v2 image sharing, community images will be displayed in an images response when the 'visibility' filter is applied with the value 'community':
GET /v2/images?visibility=community
The image-list request will respect all other appropriate filters. In particular, it should be possible to include an 'owner' parameter with a tenant id as a value, and the response will be filtered to display only those community images owned by that particular tenant:
GET /v2/images?visibility=community&owner={tenantId}
Question: what about member_status? Except for 'accepted', the other member statuses don't apply. If we do allow users to "accept" community images into their image lists, we should probably provide a way to filter to show accepted (default), non-accepted, and all.
Adding/Removing 'Community' Visibility
POST /v2/images/{image_id}/community
DELETE /v2/images/{image_id}/community
That feels a little weird, you're not really creating and removing a community resource. Another possibility would be to overload the members call:
POST /v2/images/{image_id}/members
request body: { "member": "*" }
I don't like that because it mixes "shared" and "community" visibility, which I think are distinct. For instance, it makes sense to "reject" a shared image (you are saying to the producer, you shared that image specifically with me but I don't want it.) With community images, the proper response to an image you don't like is to just ignore it.
Accepting a 'Community' Image
If we're going to allow a user to "accept" a community image into their image-list, it seems like the image should have a member list. So we could do: PUT /v2/images/{image_id}/members/{member_id} request body: {"status": "accepted"}
To un-accept a community image, you could do a PUT with body {"status":"rejected"} (and then you'd be removed from the member list?). I'm not sure how I like this. On the other hand, if we went this way, it would make sense to use the POST to members to create a community image.
