Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-56433

[v2] oc-mirror v2 generate non-unique archive file names

XMLWordPrintable

    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • CLID Sprint 271
    • 1
    • Done
    • Bug Fix
    • Hide
      * Previously, when re-running oc-mirror plugin v2 with the same working directory, existing `tar` archive files from previous runs were not removed. This resulted in a mix of outdated and new archives, which could cause mirroring failures when pushing to the target registry.

      With this update, oc-mirror plugin v2 automatically deletes old `tar` archive files at the beginning of each run, ensuring that the working directory only contains archives from the current execution. (link:https://issues.redhat.com/browse/OCPBUGS-56433[OCPBUGS-56433])
      Show
      * Previously, when re-running oc-mirror plugin v2 with the same working directory, existing `tar` archive files from previous runs were not removed. This resulted in a mix of outdated and new archives, which could cause mirroring failures when pushing to the target registry. With this update, oc-mirror plugin v2 automatically deletes old `tar` archive files at the beginning of each run, ensuring that the working directory only contains archives from the current execution. (link: https://issues.redhat.com/browse/OCPBUGS-56433 [ OCPBUGS-56433 ])
    • None
    • None
    • None
    • None

      This is a clone of issue OCPBUGS-54443. The following is the description of the original issue:

      Description of problem:

          oc-mirror to disk generates archive file names like, mirror_000001.tar, which are not unique between each run of the mirror to disk process as they were in the oc mirror v1 plugin. With v1 the files looked like mirror_seq2_000001.tar. Having non-unique names means that we cannot drop tar files from subsequent oc mirror runs into the same directory in the offline environment and push the images to disk. The flow for multiple runs of oc-mirror to disk and disk to mirror for updates would be a complex dance of different directories. Even if all the tar archives are deleted after every pull/push, we still cannot look at the file names and understand what "run" of oc mirror we're looking at.

      Version-Release number of selected component (if applicable):

          4.18.6

      How reproducible:

          100%

      Steps to Reproduce:

          1. Create an imageset-config.yaml with an OCP release and 1 small operator.
          2. oc-mirror-4.18.6 --v2 ./imageset-config.yaml file:///opt/mirror
          3. Notice the mirror_0000001.tar and its size
          4. Add an operator to the imageset-config.yaml
          5. Run the same oc mirror command to pull down the new operator images
          6. Note that the mirror_000001.tar is now a different size.
          

      Actual results:

          the archive tar files on disk get overwritten on each oc-mirror to disk run

      Expected results:

          oc mirror generates unique file names per run like the oc mirror v1 plugin did.

      Additional info:

          There's nothing in the docs that says this will happen. Overwriting or deleting files by default without warning is generally something to avoid. Many users would keep these archive files around just in case they needed to move them into the offline environment again to do something like rebuild the container registry.
      
         Also note, when mirroring to disk, oc mirror v2 does not allow the "--workspace" directory to be set so I cannot work around it that way either. The only workaround is to copy the "file:///" directory between each "run" of oc-mirror to disk and save it myself.

              rdossant Rafael Fonseca dos Santos
              openshift-crt-jira-prow OpenShift Prow Bot
              None
              None
              Nidan Gavali Nidan Gavali
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: