Bug 1679973
| Summary: | Sometimes can not connect to api server | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Junqi Zhao <juzhao> |
| Component: | Master | Assignee: | Michal Fojtik <mfojtik> |
| Status: | CLOSED ERRATA | QA Contact: | Xingxing Xia <xxia> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.0 | CC: | aos-bugs, deads, jokerman, juzhao, mmccomas |
| Target Milestone: | --- | ||
| Target Release: | 4.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-04 10:44:26 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: | |||
Where are you running this from. 1. master node -> direct to master node 2. pod -> service network -> master 3. pod -> pod network -> master 4. external -> elb -> master (In reply to David Eads from comment #1) > Where are you running this from. > > 1. master node -> direct to master node > 2. pod -> service network -> master > 3. pod -> pod network -> master > 4. external -> elb -> master from master node From master node using which route to the server? Directly to the master? Doing that, you would expect API requests to be dropped before the server is healthy. It accepts requests before it is healthy, but does not join the service until passes a health check (In reply to David Eads from comment #3) > From master node using which route to the server? Directly to the master? > Doing that, you would expect API requests to be dropped before the server is > healthy. It accepts requests before it is healthy, but does not join the > service until passes a health check I sshed to the master, and run the commands there, will try again today, since it's not always happen, not sure whether it can be reproduced or not Not reproduced with # oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-02-26-125216 True False 6h12m Cluster version is 4.0.0-0.nightly-2019-02-26-125216 I believe this was fixed recently as we now wait for discovery to contain all CRD and api's before reporting ready from apiserver. no such issue with 4.0.0-0.nightly-2019-03-06-074438, api-server performs well 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-2019:0758 |
Description of problem: run the following loop, when the number reaches to 8, "the server could not find the requested resource (get projectrequests.project.openshift.io)" and later connected to api server. $ for i in {1..19}; do echo $i; oc new-project test$i; oc new-app centos/ruby-25-centos7~https://github.com/sclorg/ruby-ex.git; sleep 15s; done 8 Error from server (NotFound): the server could not find the requested resource (get projectrequests.project.openshift.io) warning: Cannot find git. Ensure that it is installed and in your path. Git is required to work with git repositories. .... 9 Now using project "test9" on server "https://api.**.qe.devcluster.openshift.com:6443". project "test8" are not created $ oc get ns | grep test test1 Active 38m test10 Active 36m test11 Active 36m test12 Active 35m test13 Active 35m test14 Active 35m test15 Active 35m test16 Active 34m test17 Active 34m test18 Active 34m test19 Active 33m test2 Active 38m test3 Active 38m test4 Active 38m test5 Active 37m test6 Active 37m test7 Active 37m test9 Active 36m Version-Release number of selected component (if applicable): $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-02-21-215247 True False 7h Cluster version is 4.0.0-0.nightly-2019-02-21-215247 How reproducible: Sometimes Steps to Reproduce: 1. See the description part 2. 3. Actual results: Sometimes can not connect to api server Expected results: api server should be stable Additional info: