Bug 1493376
| Summary: | installer is using "latest" tag of cri-o image as hardcode | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Johnny Liu <jialiu> |
| Component: | Installer | Assignee: | Giuseppe Scrivano <gscrivan> |
| Status: | CLOSED ERRATA | QA Contact: | Johnny Liu <jialiu> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.7.0 | CC: | aos-bugs, dma, jokerman, mmccomas, sdodson |
| Target Milestone: | --- | ||
| Target Release: | 3.7.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-11-28 22:11:25 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: | |||
I'm not sure that we should use 'v3.7' but I'm not certain how cri-o would be tagged. If it's only tagged 'latest' when it's been QE'd then that's fine. Origin and OCP can ship different versions of course via docker hub and via registry.access.redhat.com so origin could be more aggressive in pushing changes. If we could confirm that cri-o image with "latest" tag is always supposed to be working in different versions of ocp in the future, using "latest" tag is okay for me. E.g: cri-o image built for 3.8 with "latest" tag also work with 3.7. About different version for Origin and OCP, I think service catalog installation playbook give us a good example, for origin and ocp, installer set different registry url and tag version according to different deployment. we are doing the same thing with the docker system container, should we change that as well to not hardcode "latest"? My guess is yes, that we should bind container-engine/cri-o to the same tag used by OCP. Even if it is possible to override the image URL, I think by default we should add the tag. For origin lets default to 'latest' for OCP lets default to the value of openshift_release which would be 'v3.7', 'v3.8', etc? We'll need to make sure that RCM begins tagging the cri-o images in that manner when they're built and released, do we think that would be a challenge? I've opened a WIP PR here: https://github.com/openshift/openshift-ansible/pull/5490 Do you agree on the logic there? Sorry to not notice the review request in comment #5. I do not think the fix PR is good enough. Now the PR make openshift_image_tag be a required inventory variable (before it is not). Generally openshift_image_tag is only used to specify an exact container image tag to install or configure when running a containerized install, and in QE's daily testing, especially pre-release testing, we only specify openshift_release for installation, installer would lookup the latest exact version of the container images, the old logic is perfect. In my initial bug report, I was requesting installer do some similar behavior like https://github.com/openshift/openshift-ansible/blob/master/roles/openshift_service_catalog/vars/openshift-enterprise.yml#L3. The CRI-O and Docker containers are special cases, since they need to be installed before any other container is running. Currently openshift-ansible in the containerized installation uses a container to check the correct version so we would need something like: 1) install crio/docker 2) check version launching a container 3) reinstall the correct crio/docker version This looks unnecessary and as agreed with Scott (https://bugzilla.redhat.com/show_bug.cgi?id=1493376#c4) we will change openshift_image_tag to be required. According to https://bugzilla.redhat.com/show_bug.cgi?id=1368034#c1, openshift_image_tag should be very precise, now once openshift_image_tag become required, is it possible to only set openshift_image_tag=v3.7 for containerized install without openshift_release? BTW, according to https://github.com/openshift/openshift-ansible/pull/5490/files#diff-1168cdcd8e452d9d950e10510f54a158R13, seem like a common rpm install also need set openshift_image_tag, that means openshift_image_tag is required in all kinds of installation, whaterever rpm install or containerized install. Once confirm, seem like openshift_release is meaningless, need cleanup for it? also we need a doc bug to track this change. I've opened a PR to use openshift_release by default: https://github.com/openshift/openshift-ansible/pull/5695 *** Bug 1494357 has been marked as a duplicate of this bug. *** Seem like have some issues (duplicated 'v' prefix) in the PR, pls refer to the PR to get my comment. additional pr merged The PR is already merged into openshift-ansible-3.7.0-0.148.0.git.0.b35eb14.el7.noarch, move it to ON_QA. Verified this bug with openshift-ansible-3.7.0-0.148.0.git.0.b35eb14.el7.noarch, and PASS. setting the following options, trigger a containerized install. openshift_use_crio=true openshift_release=v3.7 Installer is pulling openshift3/cri-o:3.7. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:3188 |
Description of problem: Go though roles/docker/tasks/systemcontainer_crio.yml, installer is pulling and running cri-o container with "latest" tag as hardcode. - name: Set the full image name set_fact: l_crio_image: "{{ l_crio_image_prepend }}/{{ l_crio_image_name }}:latest" it should allow user specify tag version (default tag should be v3.7) just like other components (metric/logging/server catalog/asb). Already requested "v3.7" tag for cri-o image in https://bugzilla.redhat.com/show_bug.cgi?id=1490323 Version-Release number of the following components: openshift-ansible-3.7.0-0.126.4 How reproducible: Awlasy Steps to Reproduce: 1. 2. 3. Actual results: Please include the entire output from the last TASK line through the end of output if an error is generated Expected results: Additional info: Please attach logs from ansible-playbook with the -vvv flag