Glance-v2-community-image-visibility-design
Revision as of 21:39, 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 'visibility' column defined as a tinyint. Should we use tinyint values instead of strings for faster db queries?
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
- Currently, the 'visibility' is mapped to a boolean as follows. This should stay the same.
if visibility == public: image.is_public = True else: image.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
- 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 and it doesn't have the concept of member status.