Glance-v2-community-image-visibility-design

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 '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:

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

(4) changing the visibility of an image

   a. changed by PATCH
   b. "publicizing" an image is protected by policy (default: admin only)
   c. QUESTION: what about "un-publicizing"?  should this also be protected
      by policy, or just allow the owner to do it?
   d. transitions:
      (NOTE: some transitions will delete all image members, make
      sure docs note this and suggest user get & save member list
      before making such a change to 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

(5) database migration

   a. all rows with is_public == 1: visibility <- public
   b. for all unique image_id in image_members where deleted != 1:
      visibility <- shared
   c. for all rows with visibility == null: visibility <- private
   d. (there are no community images yet, so nothing to do for them)

(6) impact on v1

   a. if visibility == public:
          image.is_public = True
      else:
          image.is_public = False
   b. the v1 image sharing code:
      1.  in addition to adding the image member with status 'pending'
          (as done currently), will have to change visibility <- shared
      2.  when a member is deleted, check if member-list has become
          empty; if so, change visibility <- private