Closed knowledge1st closed 1 month ago
sseago
commented
6 months ago 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
commented
6 months ago 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
commented
6 months ago "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
commented
6 months ago 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!
openshift-bot
commented
3 months ago Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
openshift-bot
commented
2 months ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten /remove-lifecycle stale
openshift-bot
commented
1 month ago Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
openshift-ci[bot]
commented
1 month ago @openshift-bot: Closing this issue.
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:
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.