Bug 1551862 - OpenShift package health check shouldn't fail while a higher docker version checked then requested
Summary: OpenShift package health check shouldn't fail while a higher docker version ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 3.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.7.z
Assignee: Luke Meyer
QA Contact: Johnny Liu
URL:
Whiteboard:
: 1562098 1562099 (view as bug list)
Depends On:
Blocks: 1551872
TreeView+ depends on / blocked
 
Reported: 2018-03-06 03:01 UTC by Gan Huang
Modified: 2018-04-10 15:20 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: The package_version check looks at the available version of docker that would be installed without the yum excluders. Consequence: This check fails for releases 3.6 and 3.7 (which don't support docker-1.13) if docker-1.13 is even available to install, even if the excluders would prevent it. Fix: Stop checking for docker version at all and simply rely on excluders functioning as intended. Result: No more false positives about this.
Clone Of:
: 1551872 (view as bug list)
Environment:
Last Closed: 2018-04-09 14:18:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3376031 0 None None None 2018-03-08 21:07:05 UTC

Description Gan Huang 2018-03-06 03:01:41 UTC
Description of problem:
If docker-1.13 is present on the repository, OpenShift health-check would check a higher docker version than requested and fail immediately. This is not reasonable because the higher docker version that installer checks may not what the user will use or install. 

We already have atomic-openshift-docker-excluder that prevents from installing incorrect docker version, instead the OpenShift health check should check if the supported docker version is available on current repository.

Version-Release number of the following components:
openshift-ansible-3.7.36-1.git.0.0f4a93c.el7.noarch.rpm

How reproducible:
always

Steps to Reproduce:
1. Trigger rpm installation on RHEL that have docker-1.12, docker-1.13 repo configured.


Actual results:
Failure summary:


  1. Hosts:    qe-ghuang-master-etcd-xxx.qe.rhcloud.com, qe-ghuang-node-registry-router-xx.qe.rhcloud.com
     Play:     OpenShift Health Checks
     Task:     Run health checks (install) - EL
     Message:  One or more checks failed
     Details:  check "package_version":
               Some required package(s) are available at a version
               that is higher than requested
                 docker-1.13.1
               This will prevent installing the version you requested.
               Please check your enabled repositories or adjust openshift_release.


Expected results:
If docker-1.12 is what we're going to support in 3.7, we just need to check if docker-1.12 is available on the host regardless of docker-1.13 or others.

Additional info:
Please attach logs from ansible-playbook with the -vvv flag

Comment 2 Luke Meyer 2018-03-09 12:14:19 UTC
The obvious workaround while 3.6 and 3.7 are waiting for this fix is to disable the check with something like this in the inventory:

openshift_disable_check=package_version

The installer should install the correct version anyway. However if you are installing docker prior to running an install, ensure that you have installed docker-1.12 and not docker-1.13 for these versions.

Comment 5 Luke Meyer 2018-03-12 23:28:19 UTC
It turns out that the excluder *doesn't* currently exclude docker 1.13. That excluder update has been built for some time and should be released soon, but it will likely not help much. Refer to https://access.redhat.com/solutions/3376031 for how to proceed.

This bug may actually be to our benefit if it leads to users landing on that kbase.

Comment 6 Scott Dodson 2018-04-09 14:18:51 UTC
This fix was shipped in openshift-ansible-3.7.42-1

Comment 7 Scott Dodson 2018-04-10 15:19:31 UTC
*** Bug 1562098 has been marked as a duplicate of this bug. ***

Comment 8 Scott Dodson 2018-04-10 15:20:06 UTC
*** Bug 1562099 has been marked as a duplicate of this bug. ***


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