summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBelmiro Moreira <moreira.belmiro.email.lists@gmail.com>2018-02-16 18:21:24 +0100
committerBelmiro Moreira <moreira.belmiro.email.lists@gmail.com>2018-05-23 12:26:26 -0700
commit801a955c78169bc53cf458051870562250dc13c2 (patch)
tree216baacc8aef02a308126f024a564e3aa9cf7c91
parentef0df98f9e89225661ecfabc66babce2a5b47304 (diff)
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
Notes
Notes (review): Code-Review+1: Andy Botting <andy@andybotting.com> Code-Review+1: Jean-Philippe Evrard <jean-philippe@evrard.me> Code-Review+1: Abhishek Kekane <akekane@redhat.com> Code-Review+1: Brian Rosmaita <rosmaita.fossdev@gmail.com> Code-Review+2: Erno Kuvaja <jokke@usr.fi> Workflow+1: Erno Kuvaja <jokke@usr.fi> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Thu, 07 Jun 2018 18:44:15 +0000 Reviewed-on: https://review.openstack.org/545397 Project: openstack/glance-specs Branch: refs/heads/master
-rw-r--r--specs/rocky/approved/glance/operator-image-workflow.rst183
1 files changed, 183 insertions, 0 deletions
diff --git a/specs/rocky/approved/glance/operator-image-workflow.rst b/specs/rocky/approved/glance/operator-image-workflow.rst
new file mode 100644
index 0000000..fa9fd97
--- /dev/null
+++ b/specs/rocky/approved/glance/operator-image-workflow.rst
@@ -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====================================
8Operator maintained images lifecycle
9====================================
10
11https://blueprints.launchpad.net/glance/+spec/hidden-images
12
13This spec addresses the problem that cloud operators have into keep a
14public image list with only the latest images versions available.
15
16Problem description
17===================
18
19Cloud operators supply *public images* that can be used by end users to boot
20servers. An example is an image containing the CentOS 7 operating system.
21Such images must be updated as security concerns, etc., are addressed. In
22Glance, however, image data is immutable, so each update results in a new
23public image. Further, operators do not want to delete the "old" public
24images, as end users may require them for different use cases like server
25rebuilds. As a result, the default image-list for end users becomes very
26large. Further, the default image-list may contain multiple CentOS 7 images,
27for example, making it difficult for end users to determine which image to
28use.
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
44A current practice is to address this by adding a custom property on an
45image, for example, ``"is_current": "yes"``, but this is operator-specific and
46not interoperable. This only solves part of the problem, however, because end
47users must be educated to look for the ``"is_current"`` image property. It
48would be better if *only* those images with ``"is_current": "yes"`` were
49included in the end user's default image-list in the first place.
50
51
52Proposed change
53===============
54
55This spec proposes adding a new boolean column ``"hidden"`` in images table.
56Images where ``"hidden" = True`` will be omitted from the image list presented
57to the user. This will apply to all image visibilities.
58However, 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
69If the image has ``"hidden" = False`` the image is not omitted from the image
70list. It preserves the current behaviour.
71
72At image creation, if not specified, it's used ``"hidden" = False``.
73
74Changing the property "hidden" will be considered an image update. Because,
75the policy is already defined for this operation no other changes are required.
76
77All operations in the image will continue to be available considering the
78policy defined.
79
80
81Alternatives
82------------
83
84Instead using a new image property we can have a new visibility = "hidden".
85Images with this new visibility state will not be in the default image list.
86To list images with visibility "hidden" it will be required to explicitly
87request it. Ex:
88``"property --visibility=hide"``
89Images with the visibility "hidden" will always be discoverable by the user.
90
91This solution is less flexible because visibility "hidden" has potentially
92the same scope as "public". The user roles that can use this visibility
93need to be controlled by policy.
94
95Another approach is to use the proposed new image property "hidden" but not
96make these images discoverable with the API. However, there is the use case
97where a project may require a particular image version (for example: different
98OS releases like CentOS7.4 to CentOS7.5; appliance vendors that support their
99software on particular images). If "hidden" images are not discoverable cloud
100admins will need implement their own solution to expose these images.
101
102
103Data model impact
104-----------------
105
106Add the "hidden" boolean column in images table.
107
108For the E-M-C migration strategy is proposed:
109- Triggers: not required. Queens release will reject an image-update call
110setting '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
116REST API impact
117---------------
118
119A new property "hidden" will be accepted for the GET call.
120GET v2/images ... hidden=true/false
121By default the API will consider hidden=false.
122
123Security impact
124---------------
125
126None
127
128Notification impact
129-------------------
130
131None
132
133Other end user impact
134---------------------
135
136The end user needs to be aware that the Cloud provider may "hide" old
137images. This is specific to each Cloud provider.
138
139
140Performance impact
141------------------
142
143None
144
145Developer impact
146----------------
147
148None
149
150Implementation
151==============
152
153Assignee(s)
154-----------
155
156Primary assignee:
157- Belmiro Moreira
158
159Work 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
167Dependencies
168============
169
170None
171
172Testing
173=======
174
175TBD
176
177
178References
179==========
180
181- https://review.openstack.org/#/c/327980
182- https://review.openstack.org/#/c/108574
183- https://review.openstack.org/#/c/508133 \ No newline at end of file