Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1581185

Summary: [svcat]`-v, --v Level ` option value type and scope are not clear
Product: OpenShift Container Platform Reporter: sunzhaohua <zhsun>
Component: Service CatalogAssignee: Marko Luksa <mluksa>
Status: CLOSED NEXTRELEASE QA Contact: Dongbo Yan <dyan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.10.0CC: chezhang, jaboyd, jiazha, zhsun, zitang
Target Milestone: ---   
Target Release: 3.11.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-30 06:33:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description sunzhaohua 2018-05-22 09:56:56 UTC 
Description of problem:
-v, --v Level ` option value type and scope are not clear.

Version-Release number of selected component (if applicable):
# svcat version
client: v3.10.0-0.50.0;Upstream:v0.1.19
server: v1.10.0+b81c8f8

How reproducible:
Always

Steps to Reproduce:
1.run `svcat --help` and `oc plugin svcat --help` and `svcat get broker --help`
2.
3.

Actual results:
The value type and scope are not specified clearly.

# svcat --help
-v, --v Level             log level for V logs


Expected results:
The type and scope should be specified clearly. I think we should specified separately for three scopes of flags. For svcat's foo command flags and global svcat flags maybe we can refer to `oc options` to set it as "--v=0: Set the level of log output (0-10)". For oc flags we keep default is ok.

Three scopes of flags:
- the local flags used by svcat's foo command
- the global svcat flags
- the global oc flags


Additional info:
Comment 1 Jay Boyd 2018-08-22 18:31:55 UTC 
The current help information for -v is consistent with kubectl and oc.  I'm hesitant to try to get upstream agreement on changing this for Service Catalog.  Jian can I ask for your thoughts here?
Comment 2 Marko Luksa 2018-08-30 06:25:55 UTC 
I propose closing this, because the plugin system in Kubernetes 1.11 was redesigned so that invoking a plugin through kubectl/oc just runs the plugin binary. This means there will never be any inconsistencies between running the plugin directly and through kubectl/oc. 

Previously, there were inconsistencies because kubectl/oc added its own flags.
Comment 3 Jian Zhang 2018-08-30 07:42:11 UTC 
Jay,

IMO, we just need to indicate the type of the `-v` option, such as "-v, --v 0", the 0 indicate the Int type so that the general users can understand. Similar as the `oc options` command: " -v, --v=0: log level for V logs".
Comment 4 Marko Luksa 2018-08-30 10:07:52 UTC 
Jian,

I see what you mean and I agree with you, but sadly, it can't be done. Svcat uses a different library for parsing flags than kubectl/oc. This library prints out the default value for int flags only when it isn't 0. There's no way to change this apart from modifying the actual library. See: https://github.com/kubernetes-incubator/service-catalog/blob/2fd20f3705099e444c084710e05a0f70b96cafde/vendor/github.com/spf13/pflag/flag.go#L712
Comment 5 Jian Zhang 2018-09-04 01:29:18 UTC 
Marko,

Thanks for your information! I got it.