Hide Forgot
Problem description: End user should be informed on the usage of MetricsApiProxy and ServiceExternalIPs ,the curent command line help doc talked no about the usages Version-Release number of selected component (if applicable): openshift v1.3.0-alpha.0-267-gcd62e58 kubernetes v1.3.0-alpha.1-331-g0522e63 etcd 2.3.0 How reproducible: Always Steps to Reproduce: oadm diagnostics -h Actual Result: help doc talked zero about the usages of MetricsApiProxy and ServiceExternalIPs Expected Result: End user should be informed on the usage of MetricsApiProxy and ServiceExternalIPs Additional info: Full diag help doc: # oadm diagnostics -h This utility helps troubleshoot and diagnose known problems. It runs diagnostics using a client and/or the state of a running master / node host. $ oadm diagnostics If run without flags, it will check for standard config files for client, master, and node, and if found, use them for diagnostics. You may also specify config files explicitly with flags, in which case you will receive an error if they are not found. For example: $ oadm diagnostics --master-config=/etc/origin/master/master-config.yaml * If master/node config files are not found and the --host flag is not present, host diagnostics are skipped. * If the client has cluster-admin access, this access enables cluster diagnostics to run which regular users cannot. * If a client config file is not found, client and cluster diagnostics are skipped. Diagnostics may be individually run by passing diagnostic name as arguments. The available diagnostic names are: AnalyzeLogs ClusterRegistry ClusterRoleBindings ClusterRoles ClusterRouter ConfigContexts DiagnosticPod MasterConfigCheck MasterNode MetricsApiProxy NodeConfigCheck NodeDefinitions ServiceExternalIPs UnitStatus Usage: oadm diagnostics [options] Options: --cluster-context='': Client context to use for cluster administrator --config='': Path to the config file to use for CLI requests. --context='': The name of the kubeconfig context to use -l, --diaglevel=1: Level of diagnostic output: 4: Error, 3: Warn, 2: Notice, 1: Info, 0: Debug --host=false: Look for systemd and journald units even without master/node config --images='openshift/origin-${component}:${version}': Image template for DiagnosticPod to use in creating a pod --latest-images=false: When expanding the image template, use latest version, not release version --loglevel=0: Set the level of log output (0-5) --logspec='': Set per module logging with file|pattern=LEVEL,... --master-config='': Path to master config file (implies --host) --node-config='': Path to node config file (implies --host) --prevent-modification=false: May be set to prevent diagnostics making any changes via the API Use "oadm options" for a list of global command-line options (applies to all commands).
They are mentioned in the list of existing diagnostics: " The available diagnostic names are: AnalyzeLogs ClusterRegistry ClusterRoleBindings ClusterRoles ClusterRouter ConfigContexts DiagnosticPod MasterConfigCheck MasterNode MetricsApiProxy NodeConfigCheck NodeDefinitions ServiceExternalIPs UnitStatus " Are you saying they should be included in the Usage, e.g.: oadm diagnostics [options] [diagnostic [diagnostic ...]]
@lmeyer How about add a sentence after "* If a client config file is not found, client and cluster diagnostics are skipped." such as "* If metrics can not be found in openshift-infra namespace, the MetricsApiProxy diagnostics are skipped" ? I was just feeling that it may be confusing if end user just judge the usage from diagnostic names such as MetricsApiProxy, but it is obviously that the Usage part is only to explain the command flags, so please let me know if I should transfer this into a documentation issue instead of command line help docs. I now feel it maybe inappropriate to request to mention such kind of detailed usage inside the short cli help doc. Thanks, Xia
There actually isn't any documentation on diagnostics yet. There ought to be. I created an issue to talk about it: https://github.com/openshift/openshift-docs/issues/1996 I think the usage should be updated to indicate you can run specific diagnostics. It should probably also generically mention that diagnostics may be skipped if they aren't relevant. I think I want to avoid discussing the details of specific diagnostics.