Bug 1913225

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 ***