Description of problem: DiagnosticPod can't run on OCP 3.6.0 since image repo not correctly set, the current cli attempted to use: registry.access.../openshift3/ose-deployer:v3.6.171 should use: brew.../openshift3/ose-deployer:v3.6.171 Version-Release number of selected component (if applicable): # openshift version openshift v3.6.171 kubernetes v1.6.1+5115d708d7 etcd 3.2.1 How reproducible: always Steps to Reproduce: 1.login openshift master, run "oadm diagnostics DiagnosticPod" 2. 3. Actual results: # oadm diagnostics DiagnosticPod [Note] Determining if client configuration exists for client/cluster diagnostics Info: Successfully read a client config file at '/root/.kube/config' [Note] Running diagnostic: DiagnosticPod Description: Create a pod to run diagnostics from the application standpoint WARN: [DCli2006 from diagnostic DiagnosticPod@openshift/origin/pkg/diagnostics/client/run_diagnostics_pod.go:135] Timed out preparing diagnostic pod logs for streaming, so this diagnostic cannot run. It is likely that the image 'registry.access.redhat.com/openshift3/ose-deployer:v3.6.171' was not pulled and running yet. Last error: (*errors.StatusError[2]) container "pod-diagnostics" in pod "pod-diagnostic-test-r05ht" is waiting to start: image can't be pulled [Note] Summary of diagnostics execution (version v3.6.171): [Note] Warnings seen: 1 Expected results: Diag pod should run with this image: brew.../openshift3/ose-deployer:v3.6.171 Additional info:
You can use --images to set the correct image template string. For instance this ought to work: oadm diagnostics DiagnosticPod --images=openshift3/ose-deployer:v3.6.171 At least, assuming that image is available (should check w/ docker pull on a node). The tag, BTW, comes from the client, which has no knowledge of what the server uses or has access to. I'm not sure where it's getting the registry from here, will have to revisit how that works. Still, this shouldn't block testing or the eventual use when this is released. The same solution applies for the network diagnostic.
Just cleaning up an old bug here. It seems to be working as designed, but feel free to reopen and explain if you believe otherwise.
Reopening, this bug is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1516589 We expect default diagnostic pod image to work out of the box.
Fixed by https://github.com/openshift/origin/pull/18260
I'm trying to understand where the registry comes from here. In my testing the default image doesn't include a registry: (going back in time to just before https://github.com/openshift/origin/pull/17315 merged) $ oc adm diagnostics -h [...] --images='openshift/origin-${component}:${version}': Image template for DiagnosticPod to use in creating a pod [...] --network-pod-image='openshift/origin:v3.9.0-alpha.0': Image to use for network diagnostic pod --network-test-pod-image='openshift/origin-deployer:v3.9.0-alpha.0': Image to use for network diagnostic test pod (advancing to the present day) $ oc adm diagnostics DiagnosticPod -h --images='openshift/origin-${component}:${version}': Image template to use in creating a pod $ oc adm diagnostics NetworkCheck -h --pod-image='openshift/origin:v3.9.0-alpha.3': Image to use for diagnostic pod --test-pod-image='openshift/origin-deployer:v3.9.0-alpha.3': Image to use for diagnostic test pod If I then run the diagnostic, the pod spec gets the short version of the image and the status gets what the node expands that to (with its registry settings), e.g.: apiVersion: v1 kind: Pod metadata: name: pod-diagnostic-test-bz88q namespace: myproject spec: containers: image: openshift/origin-deployer:v3.9.0-alpha.3 [...] status: containerStatuses: - containerID: docker://e2a6d574bd132e6413dc49c958c4a96897e7bfc0d5ce03010069ba8aa0010e65 image: docker.io/openshift/origin-deployer:v3.9.0-alpha.3 This may be confusing matters as that comes from the server side. The version comes from the client; that much is clear. If the default image also sometimes has the registry added, I don't know where it comes from, but I would guess it's still the client's environment in some fashion. The user can override this already by specifying the registry in the --images template. I am fine with trimming the registry from the client's default, which would leave it open to the node to prepend a registry. But I want to make sure the templating gets represented in the help and the user's template expanded the same.
> If the default image also sometimes has the registry added, I don't know where it comes from, but I would guess it's still the client's environment in some fashion. Tracked it down - it's the OS_IMAGE_PREFIX env var at build time, which defaults to "openshift/origin" but for OCP builds is set to "registry.access.redhat.com/openshift3/ose". So the point is, the default is built into the client, and you can already override it with --images to set the registry and version that you want. And it may be built in that way to prevent OCP users from running images by default that aren't shipped by Red Hat. That leads me back to... isn't this working as designed?
*** Bug 1544661 has been marked as a duplicate of this bug. ***
closing based on https://bugzilla.redhat.com/show_bug.cgi?id=1475680#c7