Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-2271

Simplify shipping/naming of 2.7

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • None
    • Productization
    • None
    • Simplify shipping/naming of 2.7
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • 100
    • 100% 100%

      Up to 2.5 images are shipped in different repositories, one new created every 3 months for a specific 2.x release. In addition to that, images are named with versions, for instance '3scale-amp25/backend' (note the '25').

      This causes a few inconvenience:

      1) A heavy overhead in creating new image repositories every 3 months, with lots of setup that have to be requested from RCM via filling forms (Comet) and with manual processing by RCM, not to mention the extra physical resources needed (the repo, entries in the Errata Tool, Brew buildroot setups, etc.)

      2) If we have to ship a fix (like a CVE fix) for images that were last released in different 2.x releases we need to create as many different errata to fix things in for instance 3scale-amp23, 3scale-amp24, 3scale-amp25. The alternative is even worse: always ship all images in each 2.x release. This forces more testing as rebuilding an image, even with no code changes is risky and invalidates previous testing, thus taxing QE with extra work (assuming the pipelines can at least provide the new build at low cost).

      3) Creating a ImageStream to follow the latest of an image is difficult. If an image last released in 2.3 is upgraded in 2.5 it is necessary to change the image reference from 3scale-amp23/<component> to 3scale-amp25/<component>. The images should have a fixed name like 3scale-amp/<component> or even 3scale/<component> and selection should happen based on version and tags. We do have a version bump so an ImageStream can follow 2.3, 2.4 and 2.5 release versions of images by using the version with a minor (e.g. for backend 1.6, 1.7, 1.8) and still get updates for that minor via the minor tag.

      So the proposal is that we, from 2.7 onwards, ship all the images to the same channel and let the traditional image mechanisms be used for selection, thus simplifying both setup and upgrading of images (less productization pain).

      Notes:

      Our channels can now be multi-stream, which means that even we maintain more than one stream (a series of releases that supersede the previous one, in 3scale the series of all 2.x images). If one day it becomes necessary, we could set that up (e.g., if we have a 3.x stream in addition to the 2.x one they can be in the same channel). Standard tagging is being worked out for the case of multi-stream repos.

      The use of templates and operators which are updated every release does workaround the issue with the changing image names. OTOH it facilitates changing to a more sensible one.

            Unassigned Unassigned
            fnasser Fernando Nasser
            Miroslav Jaroš Miroslav Jaroš
            Andrew Mackenzie Andrew Mackenzie
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: