Bug 1475680

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