Bug 1610599 - Usage info is being printed on all errors
Summary: Usage info is being printed on all errors
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.11.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.2.0
Assignee: Maciej Szulik
QA Contact: Xingxing Xia
Depends On:
TreeView+ depends on / blocked
Reported: 2018-08-01 03:03 UTC by Clayton Coleman
Modified: 2019-10-16 06:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1748777 (view as bug list)
Last Closed: 2019-10-16 06:27:40 UTC
Target Upstream Version:
maszulik: needinfo-

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift oc pull 69 0 'None' 'closed' 'Bug 1610599: Remove RunE usage from oc' 2019-11-20 02:38:57 UTC
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:27:56 UTC

Description Clayton Coleman 2018-08-01 03:03:02 UTC
When errors occur under `oc` usage info is also being printed.  I suspect this is https://github.com/kubernetes/kubernetes/issues/66572

This is a regression in command behavior.  We should try to get this fixed in 1.12.

Comment 1 Juan Vallejo 2018-08-01 14:58:51 UTC
Clayton, could you provide a few commands / scenarios where you are running into this? Is it only when providing extraneous or invalid flags for a command?

I can only seem to run into this issue when I specify a flag that does not exist.
Additionally, I cannot replicate the issue where we print an error twice (in oc/kubectl).

Comment 2 Juan Vallejo 2018-09-04 15:10:53 UTC
In a separate discussion, we found out that this is happening on any commands that make use of Cobra's "RunE" instead of "Run".

There is an open upstream issue to track this: https://github.com/spf13/cobra/issues/340

A workaround for this would be to set the SilenceUsage field to `true` in the root command, however this silences _all_ usage errors, even the ones we do care about displaying (such as on an invalid flag given).

For the time being, we should move away from RunE.

Comment 3 Juan Vallejo 2018-09-13 15:57:19 UTC
Given that there is a current workaround, which involves moving away from using RunE as mentioned in comment 2, I am lowering the severity of this bug.

Comment 7 Maciej Szulik 2019-08-23 10:31:08 UTC
The only offender using RunE was removed in the linked PR, upstream is not using RunE anywhere.

Comment 9 Xingxing Xia 2019-09-03 14:44:37 UTC
Same as comment 1, what were the commands / scenarios hitting the issue? With invalid flag, old and newest oc behave same for me (i.e. prints all --help info):
oc new-project --name-invalid-flag my
Error: unknown flag: --name-invalid-flag

  oc new-project NAME [--display-name=DISPLAYNAME] [--description=DESCRIPTION] [flags]                                                

  # Create a new project with minimal information
  oc new-project web-team-dev

  # Create a new project with a display name and description
  oc new-project web-team-dev --display-name="Web Team Development" --description="Development project for the web team."             

      --description='': Project description
      --display-name='': Project display name
      --skip-config-write=false: If true, the project will not be set as a cluster entry in kubeconfig after being created            

Use "oc options" for a list of global command-line options (applies to all commands).

BTW, above PR only relates to oc adm release, no fix for other sub commands?

Comment 10 Maciej Szulik 2019-09-03 14:49:20 UTC
There was no actual changes that I'm aware of. The linked PR only fixed the last remaining
element that used RunE. We will be working on fixing the help upstream so that it only 
prints the flag failed w/o full help, but that won't be fixed here.

Comment 12 Xingxing Xia 2019-09-04 07:45:18 UTC
(In reply to Maciej Szulik from comment #10)
> There was no actual changes ...
OK, thanks for clarifying it. No actual changes seem to also mean no actual verification.
> We will be working on fixing the help upstream so that it only prints the flag failed w/o full help, but that won't be fixed here.
Using new bug 1748777 to track for future fix of the issue said here.

Comment 14 errata-xmlrpc 2019-10-16 06:27:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.