Bug 1301462

Summary: ${version} is interpreted as 'v1.1.1' instead of 'latest' when start up diagnostics container with "--images='openshift/origin-${component}:${version}' "specified
Product: OKD Reporter: Xia Zhao <xiazhao>
Component: ocAssignee: Luke Meyer <lmeyer>
Status: CLOSED CURRENTRELEASE QA Contact: Wei Sun <wsun>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.xCC: aos-bugs, chunchen, mmccomas
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-12 17:09:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 1 Xia Zhao 2016-01-25 06:44:17 UTC
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.

Comment 2 chunchen 2016-01-25 07:49:19 UTC
This is a bug for new features for next version 3.3, not a bug for 3.1.1

Comment 3 Luke Meyer 2016-01-25 17:45:47 UTC
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?

Comment 4 Xia Zhao 2016-01-26 02:10:40 UTC
(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

Comment 5 Luke Meyer 2016-01-27 02:32:10 UTC
Will do. How does QE normally test changes requiring latest images? I would think this comes up often.

Comment 6 Xia Zhao 2016-01-27 06:31:12 UTC
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

Comment 7 Luke Meyer 2016-01-27 15:58:05 UTC
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.

Comment 8 Xia Zhao 2016-01-28 02:16:57 UTC
(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