Bug 1475680 - DiagnosticPod can't run due to image name wrongly interpreted
DiagnosticPod can't run due to image name wrongly interpreted
Product: OpenShift Container Platform
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: 3.9.z
Assigned To: Ravi Sankar
Xingxing Xia
: OnlineStarter, Regression, Reopened
: 1544661 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2017-07-27 03:24 EDT by Xia Zhao
Modified: 2018-06-12 02:58 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-05-03 17:00:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Xia Zhao 2017-07-27 03:24:36 EDT
Description of problem:
DiagnosticPod can't run on OCP 3.6.0 since image repo not correctly set, the current cli attempted to use:
should use:

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:

Steps to Reproduce:
1.login openshift master, run "oadm diagnostics DiagnosticPod"

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:

Additional info:
Comment 1 Luke Meyer 2017-07-27 14:06:52 EDT
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.
Comment 3 Luke Meyer 2018-01-15 13:12:43 EST
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.
Comment 4 Ravi Sankar 2018-01-24 02:22:33 EST
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.
Comment 5 Ravi Sankar 2018-01-24 02:30:07 EST
Fixed by https://github.com/openshift/origin/pull/18260
Comment 6 Luke Meyer 2018-01-24 12:02:36 EST
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
  name: pod-diagnostic-test-bz88q
  namespace: myproject
    image: openshift/origin-deployer:v3.9.0-alpha.3
  - 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.
Comment 7 Luke Meyer 2018-01-24 14:05:38 EST
> 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?
Comment 9 Michal Fojtik 2018-02-13 06:53:53 EST
*** Bug 1544661 has been marked as a duplicate of this bug. ***
Comment 10 Jordan Liggitt 2018-05-03 17:00:41 EDT
closing based on https://bugzilla.redhat.com/show_bug.cgi?id=1475680#c7

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