Glance-v2-community-image-sharing

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.

Use Cases

 * 1) 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.
 * 2) A cloud provider wants to discourage users from using a public image that is getting old (e.g., missing some security patches, or no more vendor support), but doesn't want to delete the image because some users may still require it (e.g., to rebuild a server, or user has custom patches for that particular image).  The vendor could make the image a "community' image, and then (a) it won't appear in user's default image lists (so they won't know about it unless they are motivated to seek it out, e.g., by asking other users for the UUID), and (b) since it's not a "public" image any more, it doesn't imply the same level of support as a provider-supplied public image.

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.

This was open on the code review for a few weeks, several suggestions were made, in the end the consensus was ... "community".

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?

Adding/Removing 'Community' Visibility
An image owner can make an image a "community" image by using the existing image update call and changing the image's visibility to 'community': PATCH /v2/images/{image_id} request body:

The response will be the same as is currently defined for this call.

An image owner can remove an image from community circulation by again using the existing image update call and changing the image's visibility to 'private': PATCH /v2/images/{image_id} request body:

The response will be the same as is currently defined for this call.

Accepting a 'Community' Image
As a convenience to users who'd like to "bookmark" a community image by having it display in their image-list, we'll allow users to "accept" a community image in the same way it's done for v2 image sharing. The difference here is that in v2 image sharing, only the image owner may modify the images member-list. For community sharing, the entire point is that the owner wants to make the image available to all without having to maintain relationships with each of the image consumers. So we don't want to require the image producer to have to do anything to enable the "bookmark" convenience for image consumers.

So, if a consumer of a community image wants to bookmark it, it will be a two-stage process:
 * 1) The image consumer adds her tenant ID as a member of the community image.
 * 2) The image consumer accepts the image so it will appear in her image-list

The existing image-sharing API calls will be used for this. So: POST /v2/images/{image_id}/members request body:

Response is as defined for the existing v2 image sharing call. PUT /v2/images/{image_id}/members/{member_id} request body:

Response is as defined for the existing v2 image sharing call.

Note: as with regular image-sharing, the image consumer can also modify status to "pending" or "rejected".

Deleting a Member from a Community Image
For symmetry with the POST operation that any consumer can make on a "community" image, any image consumer can remove themselves as a member of a community image using the current v2 image-sharing API call: DELETE /v2/images/{image_id}/members/{member_id} No request body.

Response is as defined for the existing call.

Image Members on a Community Image
If an image owner changes the visibility of an image from 'community' to 'private', the existing member list will remain on the image. As a private image, consumers will no longer be allowed to add themselves as members to the image; the image owner will be able to modify the member-list in whatever way he wants.

If an image owner changes the visibility of an image from 'private' to 'community', the existing member list will remain on the image. This will cause minimal disruption for consumers who are already members and who have already accepted the image.

Design Discussion
Design aspects of this feature were discussed at the Juno Mid-Cycle Meet-up (July 24-25, 2014). You can find the discussion document here: https://wiki.openstack.org/wiki/Glance-v2-community-image-visibility-design