Browse Source

Hide old images from default image-list

The spec looks how operators can have more control over images
that are included in the default image list. This is achieved
with a new property 'hidden' to omit images from the users.

Change-Id: I7bba164c350e74f9d3490c77d536bffdc1ccc075
Belmiro Moreira 1 year ago
parent
commit
801a955c78
1 changed files with 183 additions and 0 deletions
  1. 183
    0
      specs/rocky/approved/glance/operator-image-workflow.rst

+ 183
- 0
specs/rocky/approved/glance/operator-image-workflow.rst View File

@@ -0,0 +1,183 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+====================================
8
+Operator maintained images lifecycle
9
+====================================
10
+
11
+https://blueprints.launchpad.net/glance/+spec/hidden-images
12
+
13
+This spec addresses the problem that cloud operators have into keep a
14
+public image list with only the latest images versions available.
15
+
16
+Problem description
17
+===================
18
+
19
+Cloud operators supply *public images* that can be used by end users to boot
20
+servers.  An example is an image containing the CentOS 7 operating system.
21
+Such images must be updated as security concerns, etc., are addressed.  In
22
+Glance, however, image data is immutable, so each update results in a new
23
+public image.  Further, operators do not want to delete the "old" public
24
+images, as end users may require them for different use cases like server
25
+rebuilds.  As a result, the default image-list for end users becomes very
26
+large.  Further, the default image-list may contain multiple CentOS 7 images,
27
+for example, making it difficult for end users to determine which image to
28
+use.
29
+
30
+.. note:: Example
31
+
32
+    An operator provides an image for CentOS 7 with a standard set of packages
33
+    as image 1. Some minor security problem is discovered in OpenSSL, so the
34
+    operator provides image 2 of CentOS 7 with updated OpenSSL. Then a kernel
35
+    vulnerability is discovered and the operator issues image 3 of CentOS 7
36
+    with updated OpenSSL and a patched kernel. Each of these is a "version" of
37
+    the image, but the same version of CentOS 7. The operator wants a new end
38
+    user to start with image 3, but a user who's been around a while longer may
39
+    want to continue to use image 1 and patch/upgrade himself (for example, the
40
+    OpenSSL update brings in a dependency that conflicts with some key software
41
+    the user is running).  If all three images have public visibility, then all
42
+    three of them will appear in an end user's default image-list.
43
+
44
+A current practice is to address this by adding a custom property on an
45
+image, for example, ``"is_current": "yes"``, but this is operator-specific and
46
+not interoperable.  This only solves part of the problem, however, because end
47
+users must be educated to look for the ``"is_current"`` image property.  It
48
+would be better if *only* those images with ``"is_current": "yes"`` were
49
+included in the end user's default image-list in the first place.
50
+
51
+
52
+Proposed change
53
+===============
54
+
55
+This spec proposes adding a new boolean column ``"hidden"`` in images table.
56
+Images where ``"hidden" = True`` will be omitted from the image list presented
57
+to the user. This will apply to all image visibilities.
58
+However, the images will continue to be discoverable.
59
+
60
+.. note:: Example
61
+
62
+    An user wants a CentOS 7 provider image, so he uses:
63
+    ``"?visibility=public"`` on the  ``GET v2/images`` call.
64
+    He sees a CentOS 7 image, but notices that it was created_at today,
65
+    so he realizes that it's not the same image that he's searching for.
66
+    So now he uses ``"?visibility=public&hidden=true"`` to get the list of all
67
+    available images.
68
+
69
+If the image has ``"hidden" = False`` the image is not omitted from the image
70
+list. It preserves the current behaviour.
71
+
72
+At image creation, if not specified, it's used ``"hidden" = False``.
73
+
74
+Changing the property "hidden" will be considered an image update. Because,
75
+the policy is already defined for this operation no other changes are required.
76
+
77
+All operations in the image will continue to be available considering the
78
+policy defined.
79
+
80
+
81
+Alternatives
82
+------------
83
+
84
+Instead using a new image property we can have a new visibility = "hidden".
85
+Images with this new visibility state will not be in the default image list.
86
+To list images with visibility "hidden" it will be required to explicitly
87
+request it. Ex:
88
+``"property --visibility=hide"``
89
+Images with the visibility "hidden" will always be discoverable by the user.
90
+
91
+This solution is less flexible because visibility "hidden" has potentially
92
+the same scope as "public". The user roles that can use this visibility
93
+need to be controlled by policy.
94
+
95
+Another approach is to use the proposed new image property "hidden" but not
96
+make these images discoverable with the API. However, there is the use case
97
+where a project may require a particular image version (for example: different
98
+OS releases like CentOS7.4 to CentOS7.5; appliance vendors that support their
99
+software on particular images). If "hidden" images are not discoverable cloud
100
+admins will need implement their own solution to expose these images.
101
+
102
+
103
+Data model impact
104
+-----------------
105
+
106
+Add the "hidden" boolean column in images table.
107
+
108
+For the E-M-C migration strategy is proposed:
109
+- Triggers: not required. Queens release will reject an image-update call
110
+setting 'hidden' with a 400 because it doesn't recognize the field.
111
+- Expand: will add a boolean "hidden" column to the images table.
112
+- Contract: not required
113
+- Data Migration: set the "hidden" column to False in all rows.
114
+
115
+
116
+REST API impact
117
+---------------
118
+
119
+A new property "hidden" will be accepted for the GET call.
120
+GET v2/images ... hidden=true/false
121
+By default the API will consider hidden=false.
122
+
123
+Security impact
124
+---------------
125
+
126
+None
127
+
128
+Notification impact
129
+-------------------
130
+
131
+None
132
+
133
+Other end user impact
134
+---------------------
135
+
136
+The end user needs to be aware that the Cloud provider may "hide" old
137
+images. This is specific to each Cloud provider.
138
+
139
+
140
+Performance impact
141
+------------------
142
+
143
+None
144
+
145
+Developer impact
146
+----------------
147
+
148
+None
149
+
150
+Implementation
151
+==============
152
+
153
+Assignee(s)
154
+-----------
155
+
156
+Primary assignee:
157
+- Belmiro Moreira
158
+
159
+Work Items
160
+----------
161
+
162
+- Add support in GET call for the property "hidden".
163
+  Consider the default "hidden=false".
164
+- Change the image table schema adding a new field.
165
+- Change the glance-client to support the new property.
166
+
167
+Dependencies
168
+============
169
+
170
+None
171
+
172
+Testing
173
+=======
174
+
175
+TBD
176
+
177
+
178
+References
179
+==========
180
+
181
+- https://review.openstack.org/#/c/327980
182
+- https://review.openstack.org/#/c/108574
183
+- https://review.openstack.org/#/c/508133

Loading…
Cancel
Save