Created attachment 1806514 [details] 504 Gateway Time-out error Description of problem: when tries to add some workloads from builder image, templates or operator backed via via /catalog/ns/default URL, Developer Catalog page keeps loading and finally user get 504 Gateway Time-out error Version-Release number of selected component (if applicable): 4.9.0-0.nightly-2021-07-27-125952 How reproducible: Always Steps to Reproduce: 1. set up a disconnected cluster 2. tries to add workloads to default project via /catalog/ns/default Actual results: 2. the page is keeping loading and 504 error is observed in browser console GET https://<console_route>/api/helm/charts/index.yaml 504 (Gateway Time-out) Expected results: 2. user can add not workloads from builder images, operator backed, templates etc successfully via console Additional info: the issue isn't reproducible on normal connected cluster. also other pages such as /import/ns/default, /deploy-image/ns/default and /samples/ns/default is loaded successfully on a disconnected cluster
Hi Team There is an error looks hit the bug 2021-11-05T03:09:54.580155499Z 2021/11/05 03:09:54 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250626' 2021-11-05T03:10:10.615380705Z 2021/11/05 03:10:10 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250728' 2021-11-05T03:10:26.567517785Z 2021/11/05 03:10:26 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250822' Have an workaround for the issue? Version 4.8.11 Thanks
Hi Team I found a workaround can maybe can avoid the issue On disconnect environment dev console had the issue 2021-11-05T03:09:54.580155499Z 2021/11/05 03:09:54 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250626' 2021-11-05T03:10:10.615380705Z 2021/11/05 03:10:10 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250728' 2021-11-05T03:10:26.567517785Z 2021/11/05 03:10:26 Failed to dial backend: 'websocket: bad handshake' Status: '403 Forbidden' URL: 'https://kubernetes.default.svc/apis/helm.openshift.io/v1beta1/helmchartrepositories?watch=true&resourceVersion=16250822' follow the step https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html/building_applications/working-with-helm-charts#helm-disabling-helm-chart-repositories_configuring-custom-helm-chart-repositories then disable the helm chart the issue has been fix # oc get HelmChartRepository -A NAME AGE redhat-helm-repo 3d18h # oc edit HelmChartRepository redhat-helm-repo spec: connectionConfig: url: https://redhat-developer.github.io/redhat-helm-charts disabled: true <===== add a new line name: Red Hat Helm Charts
I haven't tested properly but this looks like a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1989502 which was fixed recently, since it talks about the same 504 error on the /api/helm/charts/index.yaml endpoint.
I have tested this on a disconnected cluster, the devcatalog page does not load infinitely anymore. When the user clicks on `Install a Helm Chart from the developer catalog` link from the Helm nav, the catalog fails to load and shows `Error loading catalog items` after a few seconds. I have checked the network calls, the index.yaml API gives a gateway timeout error
I agree that this sounds like a duplicate of Bug 1989502. Yadan, can you verify that this was the same issue and update the customer ticket based on that feedback, or link them to the other bug? Thank you. The fix was included in the upcoming 4.10, 4.9.7+, 4.8.31+ and will be also backported to 4.7, but it's not merged yet. *** This bug has been marked as a duplicate of bug 1989502 ***
comment 8 and comment 9 are observed on a 4.10.2 disconnected cluster on GCP