When updating images in a mirrored registry, the source repository information of the imageContentSourcePolicy (ICSP) created by oc mirror becomes incomplete.

4.13.z

100%

1. For instance, using oc mirror, I mirrored the cincinnati-operator image from operator-index:v4.11. The ICSP includes the source repository definition for the cincinnati-operator.

$ cat imageset-config.yaml 
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: mirror.example.com:8443/mirror/oc-mirror-metadata
    skipTLS: false
mirror:
  platform:
    channels:
    - name: stable-4.11
      minVersion: 4.11.34
      maxVersion: 4.11.34
      shortestPath: true
      type: ocp
    graph: true
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
    packages:
    - name: cincinnati-operator
      channels:
      - name: v1

$ cat oc-mirror-workspace/results-1692156305/imageContentSourcePolicy.yaml 
---
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: generic-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.example.com:8443/ubi8
    source: registry.access.redhat.com/ubi8
---
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  labels:
    operators.openshift.org/catalog: "true"
  name: operator-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.example.com:8443/openshift-update-service
    source: registry.redhat.io/openshift-update-service
---
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: release-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.example.com:8443/openshift/release
    source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
  - mirrors:
    - mirror.example.com:8443/openshift/release-images
    source: quay.io/openshift-release-dev/ocp-release

2. Later, for updating the image, I added the cincinnati-operator image from operator-index:v4.12 to the ImageSetConfiguration and mirrored the image. The ICSP generated during this process lacks the source repository definition for the cincinnati-operator.


$ cat imageset-config-2.yaml 
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: mirror.example.com:8443/mirror/oc-mirror-metadata
    skipTLS: false
mirror:
  platform:
    channels:
    - name: stable-4.11
      minVersion: 4.11.34
      maxVersion: 4.11.34
      shortestPath: true
      type: ocp
    - name: stable-4.12
      minVersion: 4.12.22
      maxVersion: 4.12.22
      shortestPath: true
      type: ocp
    graph: true
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.11
    packages:
    - name: cincinnati-operator
      channels:
      - name: v1
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
    packages:
    - name: cincinnati-operator
      channels:
      - name: v1


$ cat oc-mirror-workspace/results-1692157365/imageContentSourcePolicy.yaml 
---
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: release-0
spec:
  repositoryDigestMirrors:
  - mirrors:
    - mirror.example.com:8443/openshift/release
    source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
  - mirrors:
    - mirror.example.com:8443/openshift/release-images
    source: quay.io/openshift-release-dev/ocp-release
 

The ICSP generated after the second mirroring does not contain the cincinnati-operator source repository information. Applying this to the cluster would result in a loss of the source repository information for the cincinnati-operator.

The ICSP produced from the second mirroring should encompass the cincinnati-operator source repository information. Shouldn't the ICSP be generated based on the contents of the ImageSetConfiguration?

Upon examining the oc-mirror.log and mapping.txt, the cincinnati-operator was not mirrored during the second mirroring.


1. Could the reason be that the Operator images used in index:v4.11 and v4.12 are identical? I suspect that because the image is already mirrored and resides in the registry, oc mirror might be skipping the mirroring of the cincinnati-operator. Is this understanding correct?

2. The ICSP generated by mirroring only describes the source repository of the images mirrored during that particular run and doesn't encompass previously mirrored images' source repositories. By applying this new ICSP to the cluster, there's a potential risk of losing source repository information, which could result in image pull failures, correct?