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

Revision as of 18:41, 11 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.

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.

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.

@@ Line 2: / Line 2: @@
 This proposal adds the ability for users to initiate one-to-all sharing of an image.  We call such an image a "community" image.
+=== 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.
 === Constraints ===