Helm installation: Renku-UI hangs at "checking user data"

Renku Admin
1

Hi Renku Team,
after figuring out some certificate issues, the Renku installation (via Helm chart) is in a state where all pods are in state “RUNNING”. Logging in to Keycloak works and the realm “Renku” is in place.
Unfortunately the login page for Renku itself doesn’t show up, but stays at the point where 3 dancing dots and “checking user data” are shown.
The logs of the renku-ui pod doesn’t show any errors, only requests with return code 200.

Any hints on where to troubleshoot this behaviour, which pod(s) are involved in this “checking user data” step, or any other thing to check ?!?!

Many thanks, Gerd

PS: I am using an external Gitlab instance, where “external” means: it is a separate instance within the same k3s cluster as Renku

2

Hello @gkoenig ,
In my experience this happens when the pod gateway-auth is unable to fetch the public key from Keycloak.
The pod tries to fetch the public key from the external URL of keycloak (e.g. for Renkulab that would be https://renkulab.io/auth/realms/Renku).
The reasons why the pod is unable to reach Keycloak from the external URL can be several, ranging from the infrastructure network not allowing the “loopback”, to a DNS resolution issue etc…
Can you check the log of the pod called <helm-release-name>-gateway-auth and see if the problem is indeed that it cannot reach Keycloak?

3

Hi @aledegano , many thanks for your prompt reply.
Indeed, the mentioned pod shows exactly 1 line of log output, if I want to open the Renku-UI url:

[2021-08-04 11:50:58,430] DEBUG in gitlab_auth: No authorization header, returning empty auth headers

This means the communication to Gitlab isn’t working properly, I guess.
Since user mgm is done in Keycloak, with which identity is the gateway-auth trying to connect to Gitlab? …is this based on the configured application for Renku within Gitlab ?!?!

Any pointers on how/where to investigate further ?

4

…and in addition to the above mentioned, the pod gateway (without -auth) also records one line of log per URL call:

[04/Aug/2021:11:58:28 +0000] "GET /api/user HTTP/1.1" 500 21 "-" "-" 10 "gitlab@file" "https://gitlab.renku.xx.yy.zz"

…and this URL https://<gitlab-url>/api/user doesn’t really exist, if I want to open it via browser I receive a 404 instead of the 500 error in the log output… which confuses me a bit :wink: