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

Latest revision as of 18:51, 6 August 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 before 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?

Open Questions

1. Should "un-publicizing" an image be controlled by policy, or should the image owner always be able to do it?
2. The visibility transitions to 'public' delete all image members ... is this desirable behavior?