Hide Forgot
Description of problem: "oc new-app --search" command failed when OpenShift is disconnected to the Internet. It still tried to access registry-1.docker.io, which is the default value for docker registry [1]. However, it seems there is no way to override this value at the offline environment. [1] https://github.com/openshift/origin/blob/v1.2.0/pkg/image/api/helper.go#L23-L29 Version-Release number of selected component (if applicable): How reproducible: unconfirmed. Steps to Reproduce: 1. Setup offline OpenShift disconnected to the Internet 2. Import all the required images into OpenShift registry 3. "oc new-app --search <search term>" Actual results: Error with below message. > dockerImageLookup: Image import failed. api.ImageImportStatus{.....} Message: "Internal Error occurred: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io: no such host:. Expected results: Ended with no error. Additional info:
it's a bug that we fail the search entirely when the registry cannot be reached, it should be a warning that is reported to the user.
Do you have a plan to override the default docker registry to the customer specific one? If we can't override it, we can't search any templates and docker images at the disconnected environment.
you don't need to override it to search for those things, you just need it to not fail when it can't reach dockerhub, which is what we will do to fix this, as I said above.
Ok so once we fixed this and it's no longer fails at the middle of search process, the search can finish and users can get all results from OpenShift templates and the other configured docker registries. Can we get a rough ETA of this fix? The customer is using 3.2.x.
I understood the customer can search if it will be warning when the default docker-hub can't be reached. However, the customer would prefer to be able to override the default registry as below reasons. 1. It will cause a delay everytime somebody searches for a docker image, as the search for "registry-1.docker.io" will have to occur and error out first 2. It will show an error and/or warning to the end user everytime they perform a docker search. This will increase our support burden for every user as they come accross this warning and alert us about it. 3. Showing an error and/or warning for an operation when the things are running correctly is bad practive in general. It's not "warning" status but "normal" status for the disconnected OpenShift environment that they can't reach to the docker-hub. Besides, this bug has no workaround at this point. Can we get a rough ETA or workaround?
Pull request that turns the lookup failure error into a warning: https://github.com/openshift/origin/pull/11436
Commit pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/1c53eba12077b664a4db18239463276160e7c49c oc new-app --search: don't require docker hub access When using oc new-app --search in environment where OpenShift server could not reach Docker Hub, oc new-app --search had failed for any query. This commit changes the behavior to print a warning and continue with what was found in other sources. Fixes bug 1378647.
Verified openshift v3.4.0.14 kubernetes v1.4.0+776c994 etcd 3.1.0-alpha.1 steps: 1.Install an openshift cluster, pull an image $ docker pull docker.io/mariadb 2.add an iptable rules to disconnect to the Internet 3.$ oc new-app --search docker.io/mariadb actual result: output a warning, and find local image W1026 05:53:50.842350 69347 dockerimagelookup.go:217] Docker registry lookup failed: Internal error occurred: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) Docker images (oc new-app --docker-image=<docker-image> [--code=<source>]) ----- docker.io/mariadb Registry: docker.io Tags: latest
*** Bug 1398330 has been marked as a duplicate of this bug. ***
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/RHBA-2017:0066