Environment:

• OCP Version: 4.2.0 upgraded to 4.20.1

• Multiarch-Tuning-Operator Version: 1.2.0

• Cluster: Multi-architecture (arm64 primary + x86 worker added)

Summary

Even with the multiarch-tuning-operator installed, OCP cluster upgrades (e.g., from 4.2.0 to 4.20.1) cause all ImageStream tags to lose their multi-arch information. The ImageStreams revert to a single-architecture state (in my case, arm64), which can cause application deployments to fail on nodes of a different architecture.

Steps to Reproduce

1. Install OCP 4.2.0 on a primary architecture (e.g., arm64).
2. Install the multiarch-tuning-operator (v1.2.0).
3. Add a new worker node from a different architecture (e.g., x86).
4. Observe that existing ImageStreams only contain arm64 images.
5. Manually update the ImageStreams to be multi-arch aware using the command:

   oc image-import <image> --import-mode="PreserveOriginal" --all
   

1. Verify that ImageStreams now correctly show multiple architectures (arm64, x86).
2. Perform an OCP cluster upgrade (e.g., from 4.2.0 to 4.20.1).
3. After the upgrade is complete, inspect the ImageStreams again

Actual Behavior

After the cluster upgrade, all ImageStream tags have reverted to their original, single-architecture state (arm64 only). The multi-arch information imported in step 5 is lost.

Expected Behavior

The multi-arch configuration of the ImageStreams should persist across OCP cluster upgrades, especially when the multiarch-tuning-operator is installed

Impact

Application deployments can fail on heterogeneous clusters after any cluster upgrade, as the scheduler cannot find a valid image for the node's architecture. This requires manual intervention (re-running the import command) after every cluster upgrade, which defeats the purpose of the operator.
Workaround: Manually re-run 

oc image-import <image> --import-mode="PreserveOriginal" --all

for all affected ImageStreams after the cluster upgrade is complete.