XML

Word

Printable

Type: Epic
Resolution: Done
Priority: Critical
Fix Version/s: openshift-4.13
Affects Version/s: None
Component/s: None
Labels:
- cee-training
- cloudpak
- green
- node

Epic Name:
Allow mirroring images by tags
Work Type:
BU Product Work
Blocked:
False
Ready:
False
Color Status:
Green
Epic Status:
To Do
Feature Link:
OCPSTRAT-104 - Image mirroring by tags
Parent Link:
OCPSTRAT-104Image mirroring by tags
Hierarchy Progress Bar:

0% To Do, 0% In Progress, 100% Done
Release Note Text:
Undefined
Target Version:

openshift-4.13

SFDC Cases Links:
SFDC Cases Counter:
SFDC Cases Open:

OCP/Telco Definition of Done
Epic Template descriptions and documentation.

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

As a developer i want to pull image by image tag instead of digest because the mirroring of arbitrary content from upstream registries is referred to by tag

Why is this important?

1) General mirroring of arbitrary content from upstream registries which is generally referred to by tag. Developers do not want to update all their manifest to use digests based references. At the same time operations teams want to provide good pull performance and introspection of this content by using a hosted registry as a transparent pull-through cache. Such a feature requests exists in ~~PROJQUAY-465~~ and it only makes business sense if CRI-O supports tag-based mirroring.

2) Multi-Arch support is becoming difficult. It's based on manifest lists which digests is a result of all the manifests in the list. Due to the support of multi-arch the amount of images customers need to mirror tripled and so has the time and storage consumption to do this. However a large portion of our customers aren't running mixed architectures and only ever require one architecture of each image to be mirrored. When only 1 out of 3 architectures is mirrored per image, the digest of the manifest list changes and the concept of disconnected clusters based on digest references breaks.

Scenarios

Acceptance Criteria

CI - MUST be running successfully with tests automated
Release Technical Enablement - Provide necessary release enablement details and documents.
...

Dependencies (internal and external)

Previous Work (Optional):

Open questions::

Done Checklist

CI - CI is running, tests are automated and merged.
Release Enablement <link to Feature Enablement Presentation>
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DEV - Downstream build attached to advisory: <link to errata>
QE - Test plans in Polarion: <link or reference to Polarion>
QE - Automated tests merged: <link or reference to automated tests>
DOC - Downstream documentation merged: <link to meaningful PR>