Description of problem: When mirroring OCP operator hub catalog content oc generates one auth request for each repository it attempts to push content to. In the case of Operator this could easily result in 100s of repositories. In each request however it authenticates against all of those repositories at once which results in massive URL lengths, often exceeding the default 4-8K request limit of registries like Quay or Harbor. This prevents mirroring of vital OpenShift content towards Red Hat Quay, Quay.io as, Harbor well as potentially other public registries which have sane limits for request lengths to prevent. Version-Release number of selected component (if applicable): tested on 4.6 and 4.7, likely also 4.5 and 4.8 How reproducible: Always with large Operator catalogs like redhat-operators or certified-operators. Steps to Reproduce: ./oc adm --insecure=true -a $XDG_RUNTIME_DIR/containers/auth.json catalog mirror registry.redhat.io/redhat/redhat-operator-index:v4.6 registry.local:8443/operatorhub will take about 20 minutes to finish planning. It will then return an error for every push attempt with the error message above. The same is happening with {{oc image mirror}}: ./oc adm --insecure=true -a $XDG_RUNTIME_DIR/containers/auth.json catalog mirror registry.redhat.io/redhat/redhat-registry.local:8443/operatorhub --manifests only ./oc image mirror --insecure=true -a $XDG_RUNTIME_DIR/containers/auth.json -f mapping.txt Adding -v=9 to oc invocations shows insanely large auth URLs for every repository being processed. Actual results: oc catalog mirror / oc image mirror fails when attempting to mirror larger OperatorHub catalogs with a response from the registry: http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=ENHANCE_YOUR_CALM, debug="" Expected results: oc authenticates against each target repository one at a time and does not generate GET requests >4K length. Mirroring proceeds. Additional info: It currently takes ~20 minutes to generate the plan for catalog mirroring, which is a separate issue.
*** This bug has been marked as a duplicate of bug 1874106 ***