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