The following part from diagnostics container is misguiding since the command can not be run inside or outside container: Available Commands: router Start a router f5-router Start an F5 route synchronizer deploy Run the deployer sti-build Run a Source-to-Images build docker-build Run a Docker build Use "openshift help <command>" for more information about a given command.
This is a bug for new features for next version 3.3, not a bug for 3.1.1
This indicates that the version of openshift in the deployer image doesn't have the latest `openshift infra` changes to introduce the pod-diagnostic command; otherwise "pod-diagnostic" should be listed in the available commands. I'm not sure on what frequency the origin image is released, probably just every time there's a version change. When I was testing this, I built images from source and used the --latest-images flag to have them run; the e2e test uses a specific version hash in --mages. This shouldn't be a problem once there's an image released with the current-latest code. Also shouldn't be a problem for OSE/AEP since all images are versioned. Do you want to track this as a bug?
(In reply to Luke Meyer from comment #3) > This indicates that the version of openshift in the deployer image doesn't > have the latest `openshift infra` changes to introduce the pod-diagnostic > command; otherwise "pod-diagnostic" should be listed in the available > commands. I'm not sure on what frequency the origin image is released, > probably just every time there's a version change. When I was testing this, > I built images from source and used the --latest-images flag to have them > run; the e2e test uses a specific version hash in --mages. > > This shouldn't be a problem once there's an image released with the > current-latest code. Also shouldn't be a problem for OSE/AEP since all > images are versioned. > > Do you want to track this as a bug? Understood, I need to test on an image released with the current-latest code. Please help change this bug status as ON-QA, and I will verify once the latest code get into the deployer image. Thanks, Xia
Will do. How does QE normally test changes requiring latest images? I would think this comes up often.
With the help from chunchen I finally get it worked by "openshift ex diagnostics --images='openshift/origin-deployer:latest'". The thing is how ${version} is interpreted when running "openshift ex diagnostics --images='openshift/origin-${component}:${version}'". On devenv-rhel7_3250, ${version} is interpreted as 'v1.1.1' instead of 'latest': openshift ex diagnostics --images='openshift/origin-${component}:${version}' docker ps -a | grep origin-deployer eed389cbd928 openshift/origin-deployer:v1.1.1 "openshift infra diag" 4 minutes ago Exited (1) 4 minutes ago k8s_pod-diagnostics.9acb6cd7_pod-diagnostic-test-rnlmn_default_925d2ef1-c4b3-11e5-9502-0ec280e8537f_316a8741 And this introduced the above error about using old origin deployer image. Consider that the help doc did not explicitly require end user to specify an exact image version for diagnostics container, this may bring some confusion if they are using the direct format from help doc: openshift ex diagnostics -h --images='openshift/origin-${component}:${version}': Image template for DiagnosticPod to use in creating a pod
I agree it is confusing, but it is how --images works everywhere. For whatever reason, the binary does not report a version of "latest" in a devenv / self-compiled scenario, instead giving the most recent numbered release. That's why this flag exists in oadm registry, oadm router, and openshift ex diagnostics: --latest-images=false: When expanding the image template, use latest version, not release version ... and node/master config have a parallel option. I'm pretty sure this is solely to enable dev/test use cases; production users should be using released images. So as awkward as it seems, I think this is working as designed. Let me know what you think.
(In reply to Luke Meyer from comment #7) > I agree it is confusing, but it is how --images works everywhere. For > whatever reason, the binary does not report a version of "latest" in a > devenv / self-compiled scenario, instead giving the most recent numbered > release. That's why this flag exists in oadm registry, oadm router, and > openshift ex diagnostics: > > --latest-images=false: When expanding the image template, use latest > version, not release version > > ... and node/master config have a parallel option. I'm pretty sure this is > solely to enable dev/test use cases; production users should be using > released images. > > So as awkward as it seems, I think this is working as designed. Let me know > what you think. Thanks for the explanation. Now I understand it's not the proper time to test this function currently. To make sure this will not really block customer, I will alternatively add a test case that will be run in the full function round before product release when the latest deployer image will be interpreted correctly by the default value ${version}. Closing this as by design. Thanks, Xia