The way of tagging images for releases, operators and additional images is different between v1 and v2. So it is necessary to have some kind of migration feature in order to enable customers to migrate from one version to the other.

Use cases:

• As an oc-mirror user, I'd like to be able to use the delete feature of v2 to delete images mirrored images with v1, so that I can keep the registry volume under control.
  • Since the algorithm is different between version, the delete feature of v2 won't find the images mirrored by v1 and the customer won't be able to delete them.

• As an oc-mirror user switching to v2, I'd like for ICSP and IDMS/ITMS cohabitation to not cause major cluster problems. 
  • the namespace used for releases in v1 is ocp/release always. In v2 this is different. So IDMS/ITMS of v2 won't recognize release images mirrored by v1.
• As an oc-mirror user switching to v2, I'd like to apply the new catalog source files without them colliding with the ones generated by v1

• As an oc-mirror v1 user, I'd like the images already mirrored in v1 to be reusable (recognized) when using oc-mirror v2, so that I don't double the storage volume of my registry unnecessarily

• As an oc-mirror user switching to v2, I'd like to be able to easily construct the openshift-install.yaml file which is necessary to create a disconnected cluster

• From Naval: Previously we were doing the mirroring with oc adm release which was pushing in the directory of our choice, but when switching to oc-mirror v2 for release mirroring, I wasn't able to "reuse" the image path that was already created using oc adm release for 4.16.5 because when specifying a path to oc-mirror, it forces two new repository that we can't chose name of. My suggestions would be to let this as an option to avoid having to do dark things like I did (honestly, since we are on a 100 Mb connectivity for pulling images, I ended up doing a crane copy of the oc adm release mirrored path into the oc-mirror v2 created path, then oc-mirror v2 again to let it detect that images were already there...)

The solutions is still to be discussed.