New Linux image naming and registration policies
Introduction
Currently, for each Linux image, there are two series of images, one
with a datestamp (e,g, _20180106_0
) and one with a _latest
name
which gets renamed to _prevN
and hidden upon a new _latest
image
registration. We have followed a roughly monthly update schedule
(aligning with the Windows world) for the datestamp images and the
_latest
images while pushing out additional _latest
images in
between occasionally based on major improvements, bug fixes or security
issues.
The rationale was to both offer images that can be used long-term (for customers that may not yet have adopted continuous deployment models) as well as a possibility for customers to have current images (which don't need a lot of online updates to be secure).
The disadvantage of the current approach is that a lot of old images are
stored on the platform and (more importantly) cause the image list to
become larger and larger, confusing customers and causing a
glance image-list
to require more than 10s of time (and at some point
even fail for clients that don't properly handle REST pagination).
We found a lot more customers using the _latest
images and thus
propose to completely drop the images with a date stamp. We have created
a possibility to hide older images from the _prevN
series in a way
that they can be continued to be used IF referenced by image UUID.
Actions
To achieve the goal of cleaning up our public image catalog, we will hide or remove old images.
In detail:
- We only delete ancient images (from 2016) which are not in use any more or don't work well any longer.
- We hide the images that still carry minor versions which we stopped using. (e.g. Standard_CentOS_7.3_latest will be hidden, please use Standard_CentOS_7_latest instead)
- We will keep two versions of each image visible, the latest and the previous one.
- All other old images will be hidden, not deleted, meaning that the
images can still be used if the user has taken a note of the
image UUID (or requests that information from our support
organisation). Note that neither renaming from
_lastest
to_prev
nor the final rename to_DATE
and the connected hiding will change the image UUID.
So the images each go through the cycle:
+-------+ +-------+ +-------+
|Image1 | |Image1 | |Image1 |
|visible| |visible| |hidden | (no more
|_latest| -> | _prev | -> |_DATE1 | -> changes)
| UUID1 | | UUID1 | | UUID1 |
+-------+ +-------+ +-------+
+-------+ +-------+ +-------+
|Image2 | |Image2 | |Image2 |
|visible| |visible| |hidden | (no more
|_latest| -> | _prev | -> |_DATE2 | -> changes)
| UUID2 | | UUID2 | | UUID2 |
+-------+ +-------+ +-------+
+-------+ +-------+ +-------+
|Image3 | |Image3 | |Image3 |
|visible| |visible| |hidden |
|_latest| -> | _prev | -> |_DATE3 |
| UUID3 | | UUID3 | | UUID3 |
+-------+ +-------+ +-------+
...
The cycling happens at least once a month, so _latest
will be at max 1
month old, _prev
max 2 months, where as the _DATE
images (only
referencable by UUID) declare their birth date in their name.
Benefits
- The amount of (new) images that are registered and stored on the platform is cut by a factor of two.
- The images showing up in the image catalog is reduced by an order of magnitude, avoiding confusion and speeding up the catalog operations.
- The Linux images are handled more similarly to the Windows images.
- Communication is easy: Images by name
_latest
are always latest and Images by UUID are stable and aging (similar to content-based addresing as used by git).
Customer recommendations
After implementation of the new policies, users have the same choices as before: Using latest or fixed images. The choice can be done by
- Always using our latest images by referencing it by the name
_latest
. - Using the the previous images by referencing it by the name
_prev
. - Staying on the same image by referencing it by UUID.
We expect most cloud users to have mechanisms in place where they can
handle change -- they are typically best served by always using our
_latest
images. However, we acknowledge that there are valid cases
where users can not deal with OS maintenance updates well and thus we
offer the ability to reference images (current ones as well as old ones)
by UUID. While we hide the old images after some time, they remain
available by UUID for a long time.
Timeline
We will introduce this new policy with the image next publish at 15th of
March 2018. This will also affect the BareMetal images, which currently
have only datestamps and will then only have a public _latest
and
_prev
and hidden datestamp images.
We will then clean up and hide the older images in the second half of March.