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
This commit is contained in:
parent
ef0df98f9e
commit
801a955c78
|
@ -0,0 +1,183 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
====================================
|
||||||
|
Operator maintained images lifecycle
|
||||||
|
====================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/glance/+spec/hidden-images
|
||||||
|
|
||||||
|
This spec addresses the problem that cloud operators have into keep a
|
||||||
|
public image list with only the latest images versions available.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Cloud operators supply *public images* that can be used by end users to boot
|
||||||
|
servers. An example is an image containing the CentOS 7 operating system.
|
||||||
|
Such images must be updated as security concerns, etc., are addressed. In
|
||||||
|
Glance, however, image data is immutable, so each update results in a new
|
||||||
|
public image. Further, operators do not want to delete the "old" public
|
||||||
|
images, as end users may require them for different use cases like server
|
||||||
|
rebuilds. As a result, the default image-list for end users becomes very
|
||||||
|
large. Further, the default image-list may contain multiple CentOS 7 images,
|
||||||
|
for example, making it difficult for end users to determine which image to
|
||||||
|
use.
|
||||||
|
|
||||||
|
.. note:: Example
|
||||||
|
|
||||||
|
An operator provides an image for CentOS 7 with a standard set of packages
|
||||||
|
as image 1. Some minor security problem is discovered in OpenSSL, so the
|
||||||
|
operator provides image 2 of CentOS 7 with updated OpenSSL. Then a kernel
|
||||||
|
vulnerability is discovered and the operator issues image 3 of CentOS 7
|
||||||
|
with updated OpenSSL and a patched kernel. Each of these is a "version" of
|
||||||
|
the image, but the same version of CentOS 7. The operator wants a new end
|
||||||
|
user to start with image 3, but a user who's been around a while longer may
|
||||||
|
want to continue to use image 1 and patch/upgrade himself (for example, the
|
||||||
|
OpenSSL update brings in a dependency that conflicts with some key software
|
||||||
|
the user is running). If all three images have public visibility, then all
|
||||||
|
three of them will appear in an end user's default image-list.
|
||||||
|
|
||||||
|
A current practice is to address this by adding a custom property on an
|
||||||
|
image, for example, ``"is_current": "yes"``, but this is operator-specific and
|
||||||
|
not interoperable. This only solves part of the problem, however, because end
|
||||||
|
users must be educated to look for the ``"is_current"`` image property. It
|
||||||
|
would be better if *only* those images with ``"is_current": "yes"`` were
|
||||||
|
included in the end user's default image-list in the first place.
|
||||||
|
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
This spec proposes adding a new boolean column ``"hidden"`` in images table.
|
||||||
|
Images where ``"hidden" = True`` will be omitted from the image list presented
|
||||||
|
to the user. This will apply to all image visibilities.
|
||||||
|
However, the images will continue to be discoverable.
|
||||||
|
|
||||||
|
.. note:: Example
|
||||||
|
|
||||||
|
An user wants a CentOS 7 provider image, so he uses:
|
||||||
|
``"?visibility=public"`` on the ``GET v2/images`` call.
|
||||||
|
He sees a CentOS 7 image, but notices that it was created_at today,
|
||||||
|
so he realizes that it's not the same image that he's searching for.
|
||||||
|
So now he uses ``"?visibility=public&hidden=true"`` to get the list of all
|
||||||
|
available images.
|
||||||
|
|
||||||
|
If the image has ``"hidden" = False`` the image is not omitted from the image
|
||||||
|
list. It preserves the current behaviour.
|
||||||
|
|
||||||
|
At image creation, if not specified, it's used ``"hidden" = False``.
|
||||||
|
|
||||||
|
Changing the property "hidden" will be considered an image update. Because,
|
||||||
|
the policy is already defined for this operation no other changes are required.
|
||||||
|
|
||||||
|
All operations in the image will continue to be available considering the
|
||||||
|
policy defined.
|
||||||
|
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Instead using a new image property we can have a new visibility = "hidden".
|
||||||
|
Images with this new visibility state will not be in the default image list.
|
||||||
|
To list images with visibility "hidden" it will be required to explicitly
|
||||||
|
request it. Ex:
|
||||||
|
``"property --visibility=hide"``
|
||||||
|
Images with the visibility "hidden" will always be discoverable by the user.
|
||||||
|
|
||||||
|
This solution is less flexible because visibility "hidden" has potentially
|
||||||
|
the same scope as "public". The user roles that can use this visibility
|
||||||
|
need to be controlled by policy.
|
||||||
|
|
||||||
|
Another approach is to use the proposed new image property "hidden" but not
|
||||||
|
make these images discoverable with the API. However, there is the use case
|
||||||
|
where a project may require a particular image version (for example: different
|
||||||
|
OS releases like CentOS7.4 to CentOS7.5; appliance vendors that support their
|
||||||
|
software on particular images). If "hidden" images are not discoverable cloud
|
||||||
|
admins will need implement their own solution to expose these images.
|
||||||
|
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Add the "hidden" boolean column in images table.
|
||||||
|
|
||||||
|
For the E-M-C migration strategy is proposed:
|
||||||
|
- Triggers: not required. Queens release will reject an image-update call
|
||||||
|
setting 'hidden' with a 400 because it doesn't recognize the field.
|
||||||
|
- Expand: will add a boolean "hidden" column to the images table.
|
||||||
|
- Contract: not required
|
||||||
|
- Data Migration: set the "hidden" column to False in all rows.
|
||||||
|
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
A new property "hidden" will be accepted for the GET call.
|
||||||
|
GET v2/images ... hidden=true/false
|
||||||
|
By default the API will consider hidden=false.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Notification impact
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The end user needs to be aware that the Cloud provider may "hide" old
|
||||||
|
images. This is specific to each Cloud provider.
|
||||||
|
|
||||||
|
|
||||||
|
Performance impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
- Belmiro Moreira
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Add support in GET call for the property "hidden".
|
||||||
|
Consider the default "hidden=false".
|
||||||
|
- Change the image table schema adding a new field.
|
||||||
|
- Change the glance-client to support the new property.
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
- https://review.openstack.org/#/c/327980
|
||||||
|
- https://review.openstack.org/#/c/108574
|
||||||
|
- https://review.openstack.org/#/c/508133
|
Loading…
Reference in New Issue