Merge pull request #17772 from sosiouxme/20171213-diagnostics-fixups

Automatic merge from submit-queue (batch tested with PRs 17762, 17790, 17772, 17653, 17655).

diagnostics: minor fixes

Just a few things I noticed needed fixing.

Author: openshift-merge-robot

pkg/oc/admin/diagnostics/cluster.go

@@ -126,7 +126,7 @@ func (o DiagnosticsOptions) buildClusterDiagnostics(rawConfig *clientcmdapi.Conf
 // attempts to find which context in the config might be a cluster-admin for the server in the current context.
 func (o DiagnosticsOptions) findClusterClients(rawConfig *clientcmdapi.Config) (*rest.Config, kclientset.Interface, bool, string, error) {
 	if o.ClientClusterContext != "" { // user has specified cluster context to use
-		if context, exists := rawConfig.Contexts[o.ClientClusterContext]; exists {
+		if context, exists := rawConfig.Contexts[o.ClientClusterContext]; !exists {
 			configErr := fmt.Errorf("Specified '%s' as cluster-admin context, but it was not found in your client configuration.", o.ClientClusterContext)
 			o.Logger.Error("CED1003", configErr.Error())
 			return nil, nil, false, "", configErr

pkg/oc/admin/diagnostics/diagnostics/README.md

@@ -52,15 +52,15 @@ logic. This provides two major benefits:
 Having configuration files where ansible places them means you will generally
 not even need to specify where to find them. Running:
 
-    oc ex diagnostics
+    oc adm diagnostics
 
 by itself will look for master and node configs (in addition to client
 config file) in the standard locations and use them if found; so this
 should make the ansible-installed use case as simple as possible. It's also
 very easy to use configuration files when they are not in the expected
 Enterprise locations:
 
-    oc ex diagnostics --master-config=... --node-config=...
+    oc adm diagnostics --master-config=... --node-config=...
 
 Having logs in journald is necessary for the current log analysis
 logic. Other usage may have logs going into files, output to stdout,
@@ -95,7 +95,7 @@ save may be your own.
 
 A diagnostic is an object that conforms to the Diagnostic interface
 (see pkg/diagnostics/types/diagnostic.go). The diagnostic object should
-be built in one of the builders in the pkg/cmd/admin/diagnostics
+be built in one of the builders in the pkg/oc/admin/diagnostics
 package (based on whether it depends on client, cluster-admin, or host
 configuration). When executed, the diagnostic logs its findings into
 a result object. It should be assumed that they may run in parallel.

pkg/oc/admin/diagnostics/diagnostics/client/run_diagnostics_pod.go

@@ -72,7 +72,7 @@ func (d *DiagnosticPod) runDiagnosticPod(r types.DiagnosticResult) {
 				{
 					Name:    "pod-diagnostics",
 					Image:   imageName,
-					Command: []string{"openshift", "infra", "diagnostic-pod", "-l", strconv.Itoa(loglevel)},
+					Command: []string{"openshift-diagnostics", "diagnostic-pod", "-l", strconv.Itoa(loglevel)},
 				},
 			},
 		},

pkg/oc/admin/diagnostics/diagnostics/network/run_pod.go

@@ -137,7 +137,7 @@ func (d *NetworkDiagnostic) runNetworkDiagnostic() {
 	// In Collection phase, results from each node are moved to the user machine where the CLI cmd is executed.
 
 	// TEST Phase: Run network diagnostic pod on all valid nodes in parallel
-	command := fmt.Sprintf("openshift infra network-diagnostic-pod -l %d", loglevel)
+	command := fmt.Sprintf("openshift-diagnostics network-diagnostic-pod -l %d", loglevel)
 	if err := d.runNetworkPod(command); err != nil {
 		d.res.Error("DNet2006", err, err.Error())
 		return