<h2>Executive Summary</h2>
<p>Currently, for each Linux image, there are two series of images, one
with a datestamp (e,g, <code>_20180106_0</code>) and one with a <code>_latest</code> name
which gets renamed to <code>_prevN</code> and hidden upon a new <code>_latest</code> image
registration. We have followed a roughly monthly update schedule
(aligning with the Windows world) for the datestamp images and the
<code>_latest</code> images while pushing out additional <code>_latest</code> images in
between occasionally based on major improvements, bug fixes or security
issues.</p>
<p>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).</p>
<p>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
<code>glance image-list</code> to require more than 10s of time.</p>
<p>We found a lot more customers using the <code>_latest</code> images and thus
propose to completely drop the images with a date stamp. We have created
a possibility to hide older images from the <code>_prevN</code> series in a way
that they can be continued to be used IF referenced by image UUID.</p>
<h2>The proposal in detail</h2>
<p>We stop creating new images with a date stamp. Only <code>_latest</code> images
will be created, previous <code>_latest</code> get renamed.</p>
<h2>New cycling of previous <code>_latest</code> images</h2>
<p>When we register a new <code>_latest</code> image, we suggest to now rename the
previous <code>_latest</code> image to carry a date stamp e.g. <code>_20180129_0</code>
instead of <code>_prevN</code>.</p>
<p>These date stamp images get hidden immediately upon rename.</p>
<p>The hidden images do NOT show up in the image catalog in the Web
Interface ("Service Console") any more, nor are they visible to normal
tenant users via the <code>glance image-list</code> invoked API call.</p>
<p>However, if a user has stored the image UUID, (s)he can still query
details on the image details using <code>glance image-show</code> and can still
create new VMs/BareMetal ("ECS") Instances from this image. Likewise, a
<code>nova rebuild</code> (redeploying the image to an existing VM) still works as
well. The web interface and <code>nova</code> also display the image name correctly
for existing VMs with (meanwhile) hidden images.</p>
<p>Option: If we need to keep older images visible for a while, we insert a
step with a <code>_prev</code> label before hiding: Sequence then could be:
<code>_latest</code> (visible) -> <code>_prev</code> (visible) -> <code>_DATE</code> (hidden). This
way no <code>_DATE</code> image can ever be referenced by name, which would lead to
breakage.</p>
<h2>Customer recommendations</h2>
<p>After implementation of the new policies, customer have the same choices
as before: Useing latest or fixed images. The choice can be done by</p>
<ul>
<li>Always using our latest images by <strong>referencing it by the name</strong>
<code>_latest</code>.</li>
<li>Staying on the same image by <strong>referencing it by UUID</strong>.</li>
</ul>
<p>We expect most cloud users to have mechanisms in place where they can
handle change -- they are typically best served by always using our
<code>_latest</code> 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.</p>
<h2>Migration</h2>
<p>To achieve the goal of cleaning up our public image catalog, we need to
hide or remove old images.</p>
<p>Here is our proposal for this:</p>
<ul>
<li>We only delete ancient images (2016) which are not in use any more
or don't work well any longer.</li>
<li>We hide the images that still carry minor versions which we stopped
using.</li>
<li>All other old images will be hidden, not deleted, meaning that the
images can still be used <strong>if</strong> the customer has taken a note of the
image UUID (or requests that information from our support
organisation).</li>
<li>We announce the new policy to customers and tell them that they need
to remember UUIDs if they chose to not use the <code>_latest</code> images.</li>
<li>We can start with the new image registration policy immediately, BUT
wait with hiding all old images only after some weeks to give
customers a bit of time to adjust.</li>
</ul>
<h2>Benefits</h2>
<ul>
<li>The amount of (new) images that we register and store on the
platform is cut by a factor of two.</li>
<li>The images showing up in the image catalog is reduced by an order of
magnitude, avoiding confusion and speeding up the catalog
operations.</li>
<li>The Linux images are handled more similarly to the Windows images.</li>
<li>Communication is easy: Images by name <code>_latest</code> are always latest
and Images by UUID are stable and aging (similar to content-based
addresing as used by git).</li>
</ul>
<h2>Timeline</h2>
<p>We suggest to align this within T-Systems and with key customers and
then implement this within February.</p>
Telekom Logo
Brand Claim