Glance-v2-community-image-visibility-design
Revision as of 21:59, 30 July 2014 by Brian-rosmaita (talk | contribs)
This is the design discussion for the full specification: https://wiki.openstack.org/wiki/Glance-v2-community-image-sharing
Contents
Values for 'visibility'
The image JSON schema will be changed so that the enum for 'visibility' is:
[ 'public', 'private', 'shared', 'community' ]
Storage in the Database
'visibility' will be stored in the database in the images table with one of the values in the above enum. The default value is: 'private'
Note: the current DB schema has the 'is_public' column defined as a tinyint. Should we use tinyint values instead of strings for faster db queries? Do we rename the 'is_public' column to 'visibility' ?
Visibility Semantics
Here are the semantics for visibility:
- visibility is orthogonal to ownership
- semantics for each of the values
- public: all users:
- have this image in default image-list
- can see image-detail for this image
- can boot from this image
- private: users with tenantId == tenantId(owner) only:
- have this image in the default image-list
- see image-detail for this image
- can boot from this image
- shared:
- users with tenantId == tenantId(owner)
- have this image in the default image-list
- see image-detail for this image
- can boot from this image
- users with tenantId in the member-list of the image
- can see image-detail for this image
- can boot from this image
- users with tenantId in the member-list with member_status == 'accepted'
- have this image in their default image-list
- users with tenantId == tenantId(owner)
- community:
- all users
- can see image-detail for this image
- can boot from this image
- users with tenantId in the member-list of the image with member_status == 'accepted'
- have this image in their default image-list
- all users
- public: all users:
- NOTE: it's possible for an image to have 'visibility' == 'shared' but have an empty member-list
Changing Image Visibility
- changed by PATCH
- "publicizing" an image is protected by policy (default: admin-only operation)
- QUESTION: what about "un-publicizing"? should this also be protected by policy, or just allow the owner to do it?
Transitions
NOTE: some transitions will delete all image members. Make sure the docs note this and suggest that the user get and save member list changing image visibility.
- private → public
- DELETE ALL MEMBERS ON IMAGE
- private → community
- no change to image member-list
- private → shared
- no change to image member-list
- public → private
- (no members on image so nothing to do about members)
- public → community
- (no members on image so nothing to do about members)
- public → shared
- (no members on image so nothing to do about members)
- community → private
- no change to image member-list
- (list will have no effect but is saved in case image is later made 'shared' or 'community')
- community → public
- DELETE ALL MEMBERS ON IMAGE
- community → shared
- no change to image member-list
- shared → public
- DELETE ALL MEMBERS ON IMAGE
- shared → private
- no change to image member-list
- (list will have no effect but is saved in case image is later made 'shared' or 'community')
- shared → community
- no change to image member-list
Database Migration
- all rows with is_public == 1: visibility ← public
- for all unique image_id in image_members where deleted != 1: visibility ← shared
- for all rows with visibility == null: visibility ← private
- (there are no community images yet, so nothing to do for them)
Impact on v1
- If the 'visibility' of an image is 'public', then v1.is_public ← True, else v1.is_public ← False.
- the v1 image sharing code will need to be modified as follows:
- in addition to adding the image member with status 'pending' (as done currently), will have to change the image's visibility ← shared
- note: I'm pretty sure that the v1 image list code treats 'pending' the same as 'accepted' for backward compatibility (there's no concept of member status in v1)
- when a member is deleted, check if member-list has become empty; if so, change visibility ← private
- v1 doesn't have the concept of a "community" image. Since is_public is False for all images with visibility != public, such images will be hidden from users.
- a user could use the v2 API to add themselves as the member of a community image ... I guess that's OK?
- in addition to adding the image member with status 'pending' (as done currently), will have to change the image's visibility ← shared