Difference between revisions of "Glance-v2-community-image-sharing"
(Created page with "Placeholder for the full specification for BP "Add community-level v2 Image Sharing" https://blueprints.launchpad.net/glance/+spec/community-level-v2-image-sharing") |
m |
||
| Line 1: | Line 1: | ||
| − | + | 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. | ||
| + | |||
| + | === 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. | ||
Revision as of 22:31, 8 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
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.
