OPM doesn't error/warn when given bad cli arguments

[eriknelson]

This is a result of some bad automation on our part, but I would have expected OPM to expliclity error and/or warn that the cli arguments were junk:

./opm index add -c docker --bundles quay.io/konveyor/mig-operator-bundle:release-1.3.2,quay.io/konveyor/mig-operator-bundle:release-1.4.5 release-1.4.6,quay.io/konveyor/mig-operator-bundle:release-1.5.0,quay.io/konveyor/mig-operator-bundle:latest --tag quay.io/konveyor/mig-operator-index:latest

Notice the bad argument behind 1.4.5 1.4.6

This causes it to silently only build with 1.3 and 1.4:

INFO[0000] building the index                            bundles="[quay.io/konveyor/mig-operator-bundle:release-1.3.2 quay.io/konveyor/mig-operator-bundle:release-1.4.5]"
INFO[0000] running /usr/bin/docker pull quay.io/konveyor/mig-operator-bundle:release-1.3.2  bundles="[quay.io/konveyor/mig-operator-bundle:release-1.3.2 quay.io/konveyor/mig-operator-bundle:release-1.4.5]"

No error.

Would have expected a complaint or a warning with this.

[timflannagan]

There's a similar gap in the opm UX when attempting to remove a specific, non-existent package from an index and the result is no error or warning message logged. IIRC, there's a BZ on the OLM component that tracks this downstream.

[exdx]

Seems like opm thinks those are bad arguments, but ignored them instead of throwing an error.

[joelanford]

It looks like opm may be interpretting release-1.4.6,quay.io/konveyor/mig-operator-bundle:release-1.5.0,quay.io/konveyor/mig-operator-bundle:latest as a separate CLI argument instead of a flag value.

We likely need to add some tighter validation in the opm cobra commands that have explicit checks for the number (and possibly shape) of non-flag arguments. (e.g. cobra.ExactArgs(1))