Add ability to pass a variables dictionary to the hub's configmap. about helm-chart HOT 15 CLOSED

There's already hub.extraConfig that you can use to pass arbitrary python code to be added at the end of jupyterhub_config.py.

from helm-chart.

Yeah, but this Python file needs to be a part of the hub image. I'd like to reuse the same image without changing it, but supply different parameters for some code inside of jupyterhub_config.py.

from helm-chart.

I'm slightly confused :) Can you help me by providing me a concrete example of a use-case you are trying to support?

from helm-chart.

Yeah, sure. I'd like to have an authenticator where the password for each user is a hash based on the username and some "salt" string concatenated to it.

So I'm running two courses at the same time, with the same hub image. The salt ensures that two users with the same username don't have the same password in the two different courses.

Course one has one values.yaml and inside of it we have:

hub:
  extraParameters:
    salt: course1_salt_lsjdlfkqw34

Course two has another values.yaml and inside of it we have:

hub:
   extraParameters:
     salt: second_salt_sdedfse5w345

But you can imagine this being useful in other scenarios where one is running multiple courses at the same time and needs to pass some variables to the hubs that are controlling these courses.

from helm-chart.

The way I've accomplished similar things in the past is with config like:

hub:
    extraConfig: |
        c.DummyAuthenticator.password = 'myverysecretpassword'

And this achieves the same effect as what you mentioned, I think? Since it's arbitrary python code, it is quite powerful and effective.

Does this accomplish what you want?

from helm-chart.

Values.hub.extraConfig gets written in the config map into hub.extra-config.py. This value itself I don't see being used anywhere.

from helm-chart.

It's loaded in https://github.com/jupyterhub/helm-chart/blob/master/images/hub/jupyterhub_config.py#L245

from helm-chart.

Oh! I assumed so far that this is a file that I have to create, I see now that it's a config variable. Neat trick.

It might do the job, I'll try, but it doesn't seem like the best option for a few reasons:

• You have to write Python code in values.yaml. Might get a little messy if you need to write more code there.
• If you need to add code that affects multiple previous settings in jupyterhub_config.py, then your code will get spread out in between these places and the extra imported Python.
• It's mixing code and config.

Maybe this is all done with the assumption that one won't need to modify jupyter_config.py, but just add small patches to it at the end?

from helm-chart.

Yeah, it's primarily meant as an escape hatch :)

Ideally, the helm config supports a whitelisted set of authenticators (and other config!) in some form & we have proper places for it in values.yaml, or it's a small addition that can be done in extraConfig. If you have to add new authenticators you have to rebuild the image anyway (to install new authenticator). If it's submitted as a patch to this repo (and we'll happily support more authenticators, as long as they aren't super specific!), you can then structure values under auth specific to that authenticator.

So yeah, there's definitely an assumption that the helm-chart has some fairly opinionated guard-rails (the structures in values.yaml) and an escape hatch that looks a little ugly but works (extraConfig). If more radical changes are needed, then rebuilding the image is the clean thing to do.

from helm-chart.

It's nice to avoid cloning the image files, as over time it might be difficult to merge new changes from this repo into your own copy, but it's probably inevitable if you want a more customized setup.

Btw, for authenticators, it might be possible to include a new authenticator without having to modify jupyterhub_config.py or copy the image files at all. You can supply the name of the authenticator class and its parameters from values.yaml and create an image that has your authenticator, with a file like this:

FROM jupyterhub/k8s-hub:v0.4
RUN pip3 --no-cache-dir install git+https://github.com/pminkov/jupyterhub-hashauthenticator

I haven't experimented with this though.

But it still seems useful to me to be able to pass your own dictionary into /etc/jupyterhub/config and use values from it in jupyterhub_config.py. This is already somewhat possible with singleuser through extra-labels and extra-env, but not possible for the hub.

The diff would look like this:

$ git diff
diff --git a/jupyterhub/templates/hub/configmap.yaml b/jupyterhub/templates/hub/configmap.yaml
index 2036b67..9dcbf8f 100644
--- a/jupyterhub/templates/hub/configmap.yaml
+++ b/jupyterhub/templates/hub/configmap.yaml
@@ -46,6 +46,9 @@ data:
   hub.extra-config.py: |
 {{ .Values.hub.extraConfig | indent 4 }}
   {{- end }}
+  {{ if .Values.hub.extraConfigVars -}}
+  hub.extra-vars: {{ toJson .Values.hub.extraConfigVars | quote }}
+  {{- end }}
   {{ if .Values.singleuser.cmd -}}
   singleuser.cmd: {{ .Values.singleuser.cmd | quote }}
   {{- end }}

I can submit a pull request if you think this is a good idea.

from helm-chart.

yeah, I agree. can you send a PR?

from helm-chart.

For the authenticators, it might be possible to make something like this work:

auth:
  type: "custom"
  authClassName: "hashauthenticator.HashAuthenticator"
  authClassParams:
    secret_key: "834e6cace4747e966c002737191619f583be814557d3f11e358232a9a28dfa7d"

This way anyone can add an authenticator without having to modify jupyterhub_config.py.

For the image, you just need to augment the existing Docker image to pip install this new Python package, as in the Dockerfile I posted earlier.

Do you think it's a good idea to try that out?

from helm-chart.

yep, I think that's doable. I'd like the structure to be more along the lines of:

auth:
   type: "custom"
   custom:
      className: "hashauthenticator.HashAuthenticator"
      params:
           secret_key: "blahblahblah"

How does that sound?

from helm-chart.

Yeah, that works.

from helm-chart.

I've also implemented more of this in the 'extraConfigMap' variable, merged into the v0.5.x branch.

from helm-chart.