Error in Authenticator.pre_spawn_start

Renku Admin
1

Hello,
I deployed renku helm chart using config file generated with the script renku/make-values.sh at master · SwissDataScienceCenter/renku · GitHub (make-values.sh -domain mydomain.com --output-file renku-values.yaml). i deployed all components in the same stack (gitlab, keycloak, renku, and jupyterhub). when I try to launch jupyterjub i browse url https://<renku_domain>/jupyterhub then i get this error message displayed in the browser: # 500 : Internal Server Error
Error in Authenticator.pre_spawn_start: TraitError The ‘image’ trait of a RenkuKubeSpawner instance expected a unicode string, not the NoneType None.

Is my issue related to config file generated by make-values.sh script ?

Thanks

2

Hi @abella91 that’s not really an error, because we don’t ever use that path to jupyterhub in renku - are you able to create a project and launch an interactive environment?

3

No, I don’t think so - the issue is that when you go to the /jupyterhub endpoint it tries to launch a user notebook server for you - we don’t really support those since we only launch named servers inside projects. The error comes from the fact that we don’t supply a default image value for a named server.
Could you try launching an environment from a project?

1 Like
4

Thank you for your help. i’m not able to launch project. I get error in gitlab pipeline "ERROR: Job failed (system failure): prepare environment: secrets is forbidden: User “system:serviceaccount:renku:default” cannot create resource “secrets” in API group “in the namespace “renku”. Check Shells supported by GitLab Runner | GitLab for more information”, when I try to launch new environment but I think this is not related to this topic. I consider this topic as solved.

5

Indeed, that sounds like a problem with your GitLab CI runners, which is somewhat independent of the initial issue. Still, this error will prevent you from building up-to-date images for your projects.

What kind of runner are you using? from the error it sounds like you are using a runner inside kubernetes?

6

@rrrrrok It is a Kubernetes Gitlab runner that I installed using helm chart

7

@abella91 make sure you do the helm install with the RBAC creation enabled for the runner - if the runner is installed together with the rest of the GitLab helm chart, you have to set this in the values file you have for the GitLab installation - see here for example. If you don’t want to let GitLab handle the RBAC automatically, you’ll need to create the service account for the runner yourself.

8

@rrrrrok, in my environment I installed renku, gitlab, keycloak in one stack from renku helm chart and installed gitlab-runner in my k8s cluster using gitlab-runner helm chart. to configure gitlab-runner to work correctly with renku,

  1. I followed steps in this link GitLab Runner Helm Chart | GitLab to do the required configuration
  2. custom configuration to work with renku:
    a) enable RBAC as you advised me by setting following value in the config file of the gitlab-runner chart:
    rbac:
    create: true
    b) in the same file, add config to existing kubernetes runner to mount volume for socket binding
    runners:
    config: |
    [[runners]]
    image = “ubuntu:16.04”
    [runners.kubernetes]
    [[runners.kubernetes.volumes.host_path]]
    name = “socketbinding”
    mount_path = “/var/run/docker.sock”
    read_only = true
    host_path = “/var/run/docker.sock”

After that, i was able to create and launch a project in renku. Thanks a lot for your help :slight_smile:

2 Likes
9

That’s great @abella91! And thanks for sharing the configuration that made it work!

Just a side comment - I’m sure you are probably aware of this, but just in case others will be reading this thread: mounting the docker socket into the runners directly and executing user-defined CI jobs there is a potential security risk - you might want to consider a root-less image-building solution like kaniko (I’ve tried this and it works - see the gitlab documenation on how to set it up and this post about another renku deployment using it) or docker running in rootless mode (have not tried this).