Bug 1862271
Summary: | Can not get deployment due to no route to host | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Paige Rubendall <prubenda> |
Component: | Networking | Assignee: | Aniket Bhat <anbhat> |
Networking sub component: | ovn-kubernetes | QA Contact: | Anurag saxena <anusaxen> |
Status: | CLOSED DUPLICATE | Docs Contact: | |
Severity: | medium | ||
Priority: | unspecified | CC: | aconstan, anbhat, aos-bugs, mfojtik, mifiedle, prubenda, skordas, sttts, xxia |
Version: | 4.6 | Keywords: | Reopened |
Target Milestone: | --- | ||
Target Release: | 4.6.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: | 2020-09-08 16:38:03 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: |
Description
Paige Rubendall
2020-07-30 20:45:40 UTC
Can you attach the output of `oc get events`? It's not clear why this should be attributed to routing - if you can't create a deployment that speaks to other resource issues. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. (In reply to Andrew McDermott from comment #2) > Can you attach the output of `oc get events`? > > It's not clear why this should be attributed to routing - if you can't > create a deployment that speaks to other resource issues. % oc logs deploymentconfig0-1-deploy -n svt-1645 error: couldn't get deployment deploymentconfig0-1: Get "https://172.30.0.1:443/api/v1/namespaces/svt-1645/replicationcontrollers/deploymentconfig0-1": dial tcp 172.30.0.1:443: connect: no route to host ^ I missed this on first reading. If your cluster is still up can you attach: $ oc get events and what does: $ oc get pods -n openshift-ingress $ oc log -n openshift-ingress <router-pod-XXX> show? I have not been able to get back to this exact state, I have hit other issues before I was able to get more detailed information Was able to get to this same error state. Attaching logs of ingress and events as private comments Here is the information from my new cluster % oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.0-0.nightly-2020-08-05-082458 True False 108m Cluster version is 4.6.0-0.nightly-2020-08-05-082458 % oc get pods -A | grep svt | grep Error svt-1366 deploymentconfig0-1-deploy 0/1 Error 0 8m36s svt-1383 deploymentconfig0-1-deploy 0/1 Error 0 8m23s svt-1397 deploymentconfig0-1-deploy 0/1 Error 0 8m9s svt-1568 deploymentconfig0-1-deploy 0/1 Error 0 5m34s svt-1585 deploymentconfig0-1-deploy 0/1 Error 0 5m15s svt-1586 deploymentconfig0-1-deploy 0/1 Error 0 5m15s svt-1591 deploymentconfig0-1-deploy 0/1 Error 0 5m11s svt-1592 deploymentconfig0-1-deploy 0/1 Error 0 5m11s svt-1595 deploymentconfig0-1-deploy 0/1 Error 0 5m4s svt-1596 deploymentconfig0-1-deploy 0/1 Error 0 5m6s svt-1597 deploymentconfig0-1-deploy 0/1 Error 0 5m5s svt-1598 deploymentconfig0-1-deploy 0/1 Error 0 5m6s svt-1600 deploymentconfig0-1-deploy 0/1 Error 0 4m58s svt-1602 deploymentconfig0-1-deploy 0/1 Error 0 4m58s svt-1603 deploymentconfig0-1-deploy 0/1 Error 0 4m58s svt-1605 deploymentconfig0-1-deploy 0/1 Error 0 4m54s svt-1607 deploymentconfig0-1-deploy 0/1 Error 0 4m54s svt-1608 deploymentconfig0-1-deploy 0/1 Error 0 4m53s svt-1611 deploymentconfig0-1-deploy 0/1 Error 0 4m48s svt-1615 deploymentconfig0-1-deploy 0/1 Error 0 4m41s svt-887 deploymentconfig0-1-deploy 0/1 Error 0 16m svt-897 deploymentconfig0-1-deploy 0/1 Error 0 16m Looking through the router logs from comment #8 and the events from comment #9 I don't see anything that hints at an ingress problem. It's not clear that ingress is failing so moving this to SDN as we see (from comment #4): % oc logs deploymentconfig0-1-deploy -n svt-1645 error: couldn't get deployment deploymentconfig0-1: Get "https://172.30.0.1:443/api/v1/namespaces/svt-1645/replicationcontrollers/deploymentconfig0-1": dial tcp 172.30.0.1:443: connect: no route to host which is an internal endpoint. Changing sub component to ovn because these clusters have been using the ovn specific configuration Please reproduce in newer build and capture must-gather output. No route to host is an SDN problem, isn't it? |