Difference between revisions of "Glance-v2-community-image-visibility-design"

Revision as of 21:59, 30 July 2014

This is the design discussion for the full specification: https://wiki.openstack.org/wiki/Glance-v2-community-image-sharing

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:

1. visibility is orthogonal to ownership
2. 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
   • 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
3. NOTE: it's possible for an image to have 'visibility' == 'shared' but have an empty member-list

Changing Image Visibility

1. changed by PATCH
2. "publicizing" an image is protected by policy (default: admin-only operation)
3. 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.

1. private → public
   • DELETE ALL MEMBERS ON IMAGE
2. private → community
   • no change to image member-list
3. private → shared
   • no change to image member-list
4. public → private
   • (no members on image so nothing to do about members)
5. public → community
   • (no members on image so nothing to do about members)
6. public → shared
   • (no members on image so nothing to do about members)
7. 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')
8. community → public
   • DELETE ALL MEMBERS ON IMAGE
9. community → shared
   • no change to image member-list
10. shared → public
    • DELETE ALL MEMBERS ON IMAGE
11. 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')
12. shared → community
    • no change to image member-list

Database Migration

1. all rows with is_public == 1: visibility ← public
2. for all unique image_id in image_members where deleted != 1: visibility ← shared
3. for all rows with visibility == null: visibility ← private
4. (there are no community images yet, so nothing to do for them)

Impact on v1

1. If the 'visibility' of an image is 'public', then v1.is_public ← True, else v1.is_public ← False.
2. 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?