[Test Plan] Test Openshift image migration workflow

[istein1]

Check on Crane the below workflow to ensure MTC's Openshift images migration is covered in Crane:
export->transform (with Openshift plugin)->apply is for manifests, skopeo copy for images in parallel.

More info on these steps in Crane can be found in
Gemini Images MTC vs Crane & Claude findings on no tests in Crane

[github-actions]

This issue is currently awaiting triage.
If contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.

[midays]

Test Flow

Prerequisites:

• crane binary with OpenShiftPlugin installed
• skopeo installed

Steps:

1. Deploy app with BuildConfig/ImageStream on source cluster
2. Wait for build to complete and ImageStream to be populated
3. crane export from source namespace
4. crane skopeo-sync-gen to generate the image sync config
5. crane transform — KubernetesPlugin stage
6. crane transform --stage 20_OpenShiftPlugin , OpenShift plugin stage
7. crane apply, generate final output
8. Login to destination cluster, create namespace
9. Expose destination internal registry route
10. skopeo copy, copy exact source image digest to destination registry
11. kubectl apply -f output/resources// , apply manifests
12. Verify on destination: pods running, ImageStream populated with correct digest, Route accessible

Pass criteria:

• All resources apply without errors (minus the ImageTag bug)
• Deployment pulls image successfully , no ErrImagePull
• ImageStreamTag on destination points to the same digest as source
• Route hostname reflects destination cluster domain
• App behavior matches source

[midays]

Tested the core functionality of openshift image migration export -> transform (KubernetesPlugin + OpenShiftPlugin) -> apply + skopeo copy workflow on OCP-to-OCP migration.

Environment:

• Source: OpenShift 4.x (cam-src-71950)
• Destination: OpenShift 4.x (cam-tgt-71950)
• crane: main branch
• OpenShiftPlugin: v0.0.4
• App: django-ex (S2I/BuildConfig-based, internal ImageStream)

---

What works

• crane export correctly captures ImageStreams, ImageStreamTags,
  BuildConfig, Route, Deployment
• crane skopeo-sync-gen correctly identifies internally-built images
  (those referencing the internal registry) and generates the skopeo sync config
• Two-stage transform (KubernetesPlugin -> OpenShiftPlugin) correctly cleans
  manifests:
  • Strips default RBAC (builder/deployer SAs, system:image-builders,
    system:deployers RoleBindings)
  • Strips /spec/host from Route, destination cluster assigns its own hostname
  • Strips OpenShift-injected CA bundle ConfigMap
  • Strips dockercfg pull secrets
• crane apply produces clean, re-appliable output
• Route hostname automatically reassigned on destination
• skopeo copy successfully transfers the exact source image digest to
  destination registry
• After skopeo copy, Deployment pulls the migrated image successfully

Bugs Found

1. ImageTag not whited out by OpenShiftPlugin
Filed: migtools/crane-plugin-openshift#25

ImageTag (image.openshift.io/v1) is a read-only server-managed projection
of ImageStreamTag and cannot be created via kubectl apply. It survives both
transform stages and fails on apply with:

The ImageTag "django-ex:latest" is invalid:
spec: Required value: spec is a required field during creation

OpenShiftPlugin should whittle it out the same way KubernetesPlugin whiteouts
Pods, ReplicaSets, and Endpoints.

2. OpenShiftPlugin not auto-staged when installed
Filed: #331

Even though OpenShiftPlugin is installed and correctly discovered
("Loaded 2 plugin(s)"), crane only auto-creates 10_KubernetesPlugin on the
default run. The OpenShiftPlugin must be manually invoked with an explicit
--stage flag. This is a silent failure for OCP migrations.

Behavioral Observations

Skopeo is required for exact image migration:
Without skopeo, the migrated ImageStreamTag contains the source image digest
which doesn't exist on the destination registry. The Deployment immediately
fails with ErrImagePull / manifest unknown. The BuildConfig eventually
triggers a rebuild which resolves the pull issue, but:

• Produces a different image with a different digest (not a true migration)
• Depends on source code still being accessible
• Creates a gap window where the app is unavailable

Skopeo step must happen before or in parallel with manifest apply not after.

BuildConfig re-triggers on destination:
Applying the migrated BuildConfig automatically triggers a new build on the
destination. This is expected behavior but worth noting, if exact image
preservation is required, the BuildConfig trigger should be disabled or
skopeo should be run first to pre-populate the registry before apply.

[istein1]

Thanks @midays for the extensive testing, bugs, and behavioral observations/requirements!

1. Are the bugs critical or have a workaround?
2. Based on your findings, does that cover MTC's Openshift images migration functionality?
3. Documentation wise:
   a. we'll need to document these bugs as known issues if they are not fixed for coming version.
   b. The "Behavioral Observations" will need to be documented as requirements /expected behaviors of Openshift images
   migration.
4. Could you open a related GH issue for automating a basic Openshift images migration flow for Crane?