Description of problem: Scenario 1: When cu follows the procedure specified in official documentation of v4.6 [https://docs.openshift.com/container-platform/4.6/operators/admin/olm-restricted-networks.html], the command `oc adm mirror catalog` fails irrespective of the oc binary version (oc client v4.5 as well as oc client v4.6) Scenario 2: When cu follows the procedure specified in the official documentation of v4.5 [https://docs.openshift.com/container-platform/4.5/operators/admin/olm-restricted-networks.html], all the steps complete as expected successfully. - When we execute the same procedure with oc binary v4.6 (or with binary v4.5) to mirror the images of version 4.6 on OCP server v4.6, it completes without any issues. We could observe that the `oc adm catalog build` command has been deprecated for several releases (highlighted in the 4.6 documentation), we are suggested to use `opm index` command to manage index images. However, the procedure seems to be not helping completely. - The customer has a query, would it be valid/appropriate if they perform the steps according to the documentation targeting to version 4.5 over an OCP cluster of version 4.6? Version-Release number of selected component (if applicable): v4.6 (Using Operator Lifecycle Manager on restricted networks procedure) How reproducible: - Follow the steps shared in the documentation: https://docs.openshift.com/container-platform/4.6/operators/admin/olm-restricted-networks.html Actual results: - `oc adm mirror catalog` command failing with the error messages in the attachments. Expected results: - No command failures to be encountered when we follow the steps suggested in the 4.6 documentation. Additional info: - We have some already existing bugs focusing on issues around the `oc adm catalog mirror` command with/without the parameter "--filter-by-os=.*" (For ex: https://bugzilla.redhat.com/show_bug.cgi?id=1908565) But, this is a slighlty different concern, as the issue is encountered specificlly when we follow the steps from OCP 4.6 version's documentation (Using Operator Lifecycle Manager on restricted networks ).
Updating the priority of the BZ per the attached case.
The problem I'm seeing from the attached files is that the command invocation is wrong in both cases, namely: oc adm catalog mirror --filter-by-os=.*. registry.redhat.io/redhat/redhat-operator-index:v4.6 xyz.com:6000/olm4.6.6-2 --manifests-only --loglevel=4 oc adm catalog mirror --filter-by-os=`.*` registry.redhat.io/redhat/redhat-operator-index:v4.6 xyz.com:6000/olm4.6.6-2 --manifests-only --loglevel=4 The only difference between the two commands is how the OS filter is being passed and both are wrong. Bash has a mechanism called globbing [1] which replaces all wildcard characters (such as .*.) into file from the current directory. Thus the above command invocations are failing. To prevent bash from interpreting these as such it is required to quote the parameter with a single or double quote, just like it is described in the docs: oc adm catalog mirror \ <index_image> \ <mirror_registry>:<port> \ [-a ${REG_CREDS}] \ [--insecure] \ --filter-by-os='.*' \ <--- notice single quote around regular expression. [--manifests-only] Please use correct command execution and if there's a problem feel free to reopen this issue with details what is failing. [1] https://tldp.org/LDP/abs/html/globbingref.html [2] https://unix.stackexchange.com/questions/67757/wildcards-inside-quotes
Hello Maciej, I agree with the difference in the regex passed, but the customer executes these commands using a shell script, and that is the reason they have made some tweaks with the regular expression. We have verified with the customer, and personally by trying various regex, it appears that if regex is the concern, the command would highlight it with the following message: ~~~ error: --filter-by-os was not a valid regular expression: error parsing regexp: missing argument to repetition operator: <invalid-experession> ~~~ Please have a look into the snippet where passing the exact expression also returns the same output (From my test env): ~~~ # oc adm catalog mirror registry.redhat.io/redhat/redhat-operator-index:v4.6 <mirror_registry>:5000 -a /root/psecret.json --insecure --filter-by-os='.*' error: the image is a manifest list and contains multiple images - use --filter-by-os to select from: OS DIGEST linux/amd64 sha256:1292aae046f118dc69d6d04f6afe4998293d14797fbb4de19049f20e015aea85 linux/ppc64le sha256:be61164b9b8f87c59a4c371559693b4a6aadeaad7e03bc15394bb10c03c669d4 linux/s390x sha256:4d3fe662a3fec088ed3aa243cb6ac46fa0ef4eb3029163e16e033cfc60d9d292 ~~~ - Also, we recently received an update on another similar BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1908565#c15 This BZ was mainly focused on the issues with `oc` client, but, it appears that the recent update might relate to the issue we are discussing here regarding the changes in the procedure. We think, this should not be considered as 'NotABug' according to the above details. Please let us know your thoughts on this. Thanks, ApoorvaJ
(In reply to Apoorva Jagtap from comment #7) > Hello Maciej, > > I agree with the difference in the regex passed, but the customer executes > these commands using a shell script, and that is the reason they have made > some tweaks with the regular expression. > We have verified with the customer, and personally by trying various regex, > it appears that if regex is the concern, the command would highlight it with > the following message: > ~~~ > error: --filter-by-os was not a valid regular expression: error parsing > regexp: missing argument to repetition operator: <invalid-experession> > ~~~ > > Please have a look into the snippet where passing the exact expression also > returns the same output (From my test env): > ~~~ > # oc adm catalog mirror > registry.redhat.io/redhat/redhat-operator-index:v4.6 <mirror_registry>:5000 > -a /root/psecret.json --insecure --filter-by-os='.*' > error: the image is a manifest list and contains multiple images - use > --filter-by-os to select from: > > OS DIGEST > linux/amd64 > sha256:1292aae046f118dc69d6d04f6afe4998293d14797fbb4de19049f20e015aea85 > linux/ppc64le > sha256:be61164b9b8f87c59a4c371559693b4a6aadeaad7e03bc15394bb10c03c669d4 > linux/s390x > sha256:4d3fe662a3fec088ed3aa243cb6ac46fa0ef4eb3029163e16e033cfc60d9d292 > ~~~ > > - Also, we recently received an update on another similar BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=1908565#c15 > This BZ was mainly focused on the issues with `oc` client, but, it appears > that the recent update might relate to the issue we are discussing here > regarding the changes in the procedure. > You are right, this looks like a duplicate of that other issue, where oc amd catalog mirror isn't handling multiple architectures. That's why in your case passing the wildcard ends with an error. Temporary workaround based on the comment you've pointed to (https://bugzilla.redhat.com/show_bug.cgi?id=1908565#c15) suggests using a particular architecture until this problem is solved with this command. *** This bug has been marked as a duplicate of bug 1908565 ***