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

Reduce the default to avoid network issues

XMLWordPrintable

    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • CLID Sprint 272, CLID Sprint 273
    • 2
    • Done
    • Bug Fix
    • Hide
      * Before this update, oc-mirror v2 sent a high number of requests to container registries, leading to some requests being rejected with `too many requests` error. With this release, the default for `maxParallelLayerDownloads` and `maxParallelImageDownloads` flags have been reduced, and the retry-times have been increased. Additionally, the retry-delay was set to `0` for exponential backoff. As a result, fewer requests are being sent to container registries, reducing the number of rejections.
      link:https://issues.redhat.com/browse/OCPBUGS-57370(OCPBUGS-57370)
      Show
      * Before this update, oc-mirror v2 sent a high number of requests to container registries, leading to some requests being rejected with `too many requests` error. With this release, the default for `maxParallelLayerDownloads` and `maxParallelImageDownloads` flags have been reduced, and the retry-times have been increased. Additionally, the retry-delay was set to `0` for exponential backoff. As a result, fewer requests are being sent to container registries, reducing the number of rejections. link: https://issues.redhat.com/browse/OCPBUGS-57370(OCPBUGS-57370)
    • None
    • None
    • None
    • None

      Description of problem:

          Currently oc-mirror v2 defaults related to concurrency are too high and some container registries are rejecting so many requests. Some customer are using some flags to avoid the network issues: In this conversation it is possible to see that --parallel-images 2 --retry-delay 2s --retry-times 5 are used https://redhat-internal.slack.com/archives/C02JW6VCYS1/p1749568315478749?thread_ts=1749566735.317039&cid=C02JW6VCYS1 there is also another customer using a similar set of flags: --retry-times 30 --image-timeout 60m --parallel-images 2 --retry-delay 2s

       

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

      How reproducible:

          It is not always reproducible, but the dev team also faced this issue so it is a known issue.

      Steps to Reproduce:

          1.
    2.
    3.

      Actual results:

      Expected results:

      Additional info:

          Reducing the defaults could be a solution.
    Also changing the default of --retry-delay to zero would change the behavior inside of containers/common/pkg/retry from linear to exponential backoff (which could help when retrying pushing the image)

       

       

              rh-ee-aguidi Alex Guidi
              rh-ee-aguidi Alex Guidi
              None
              None
              May Xu May Xu
              None
              Votes:
              97 Vote for this issue
              Watchers:
              38 Start watching this issue

                Created:
                Updated: