Allow patchlevel updates to product images independent of a full Stackable release

Introduction

This is currently mostly to write down something that @lfrancke and myself discussed last week to allow people to comment and get a discussion going.

Reasoning

Currently a patch release for SDP is somewhat simpler than a "full" release, but still creates very high effort. Ideally we'd like to be able to update products easily and frequently, in order to allow updating the base-image as well as gain the ability to push dependency updates / CVE fixes or similar things on short notice.

Since a lot of the effort is created by releasing and certifying our operators, we might solve this by decoupling product images from the operator images to a certain degree.

There is some prior art around this, the following list feels incomplete, but I was unable to find the "large" issue and discussion that I feel I remember:

• https://github.com/stackabletech/docker-images/issues/208
• https://github.com/stackabletech/docker-images/issues/260

Requirements

Whatever we decide must allow us to easily push updated product images in less than a day with minimal effort, ideally we'd just tag in docker-images and the rest just work einfach so.

Updated images should not be automatically rolled out to customer clusters, they have to explicitly choose to use a newer image in order to avoid any "magic" that is not transparent to customers. So no floating tags or similar things that would mean the same CRD results in different things being deployed depending on when they are deployed.

We must not need to certify anything for OpenShift!

Idea

We add an extra field to the version struct in our CRD, which allows specifying a product-image-patchlevel (maybe not named like this, but it nicely illustrates the point.

spec:
  image:
    productVersion: 1.2.3 
    productImagePatchlevel: 1

Which the operator can then add to the image name like this:
nifi:2.6.0-stackable26.3.0-1

So for existing CRDs nothing would change, the operator would consistently pick a stable image, but customer who want to update for some reason can switch to an updated version of the product image.

Problems

Users need to remember to remove the patchlevel when updating the product version, this is not too hard, but makes templating the version more complex and is just an extra thing that could go wrong.

This requires updating the CRD, when updating the Stackable Version, because for the new version the patchlevel will not be available. We could mitigate this by making the patchlevel release specific like for example:

spec:
  image:
    productVersion: 1.2.3 
    productImagePatchlevel:
      25.1: 1
      25.1.1: 3
      26.3: 1

Beginne damit, die verlinkten docker-images-Issues und die Diskussion in diesem Issue zu lesen; es ist kein Implementierungs-Repository, keine Datei und kein Test angegeben. Ermittle, wie Produkt-Images, Operator-Releases, CRDs und Zertifizierung derzeit repositoryübergreifend zusammenhängen. Als abgeschlossen gilt die Aufgabe, wenn ein abgestimmtes Design vorliegt, das die Anforderungen an Updates auf Patch-Ebene, explizite Image-Auswahl, Kompatibilität und OpenShift erfüllt.