Question about imagestream direct migration

[knowledge1st]

Hi everyone there, i don't know if this is the correct place to ask this.

Context: two Openshift clusters in the same version (4.12.23), openshift-mtc installed on each, openshift-adp installed on each cluster at the same namespace of openshif-mtc, there is connection between clusters, we have migrated yamls/resources between this clusters before.

I'm trying to migrate images/imagestreams/imagestreamtags DIRECTLY (using DirectImageStreamMigration) from One openshift (4.12) to another openshift (4.12), but i think i'm having troubles at this line:

https://github.com/openshift/openshift-velero-plugin/blob/3041210470217f68cd6f3b860941959f251a0521/velero-plugins/imagecopy/imagestream.go#L89C42-L89C59

if len(o.InternalRegistryPath) > 0 && strings.HasPrefix(dockerImageReference, o.InternalRegistryPath) {

I can't debug the values been used, but i think these are this:

o.InternalRegistryPath=image-registry.openshift-image-registry.svc:5000
dockerImageReference=not-openshift-internal-registry.com (this is an example... the hostname is an example to exaplain that is not the internal registry)

This would evaluate to False, and won't keep the migration.

I'm correct? Is this workaround~able? Images are only migrated if the imagestreamtags referenced uses the internal registry?

Thanks in advance, and sorry if theres errors on my side.

[sseago]

If it doesn't match, it's not "won't keep the migration" -- it's "won't migrate by copying image bits" because the image isn't located in the internal registry. If it's an external imagestream, then it's migrated by backing up and restoring the appropriate ImageStreamTag kubernetes resource. We don't need the image bits, since it's referencing a registry outside the cluster.

[knowledge1st]

Thank u for comment @sseago

I thought that it should try to copy the image from one internal registry to the another cluster internal registry. Because this image exists in the clusterA registry even is pointing to an external registry.

But you telling me that because the ImageStreamTag refers to an external registry, it will ignore copying the image between registries and just copy the yaml of the ImageStream and let the clusterB pull the image from the external registry as normal?

Is this behavior modificable?

[sseago]

"I thought that it should try to copy the image from one internal registry to the another cluster internal registry. Because this image exists in the clusterA registry even is pointing to an external registry."

We do this for purely internal images. if the image reference is external, though, then restoring the ImageStreamTag should make the image fully-functional in the destination cluster. Are you seeing errors in accessing images with external dockerImageReferences?

This is not currently configurable. For any image reference that points to the internal registry, we copy this image to the destination cluster's internal registry. If the image is referenced outside of the cluster, the assumption is that the outside reference will still be valid in the destination cluster. If you need/want your images that are external on the source cluster to be internal on the destination cluster, that seems like functionality beyond simple migration -- that's more of a configuration change, so it should probably be made either before or after migration.

[knowledge1st]

The real reason is that, clusterA is hosted onprem and clusterB is on AWS, and the external registry we use is hosted on another ocp cluster hosted onprem too... so when clusterB tries to pull from external registry, it takes long times to do that.

The idea was to copy clusterA internal registry images directly to clusterB internal registry, to prevent this behavior of clusterB pulling for long times.

But wasn't my purpose change the way this plugin works, just know how it does what it does and if there was an option/flag to force to copy the image even when the reference was an external registry.

Thanks a lot sseago!