simplify singleuser server image parsing by removing stanza from hubploy.yaml and use the default z2jh method#127
Conversation
|
ok, this is better (and basically works as advertised), but the logic around setting images is... wonky AF. i'm gonna take a quick break and think about what i can do to refactor/clean it up. |
by deleting the wonky logic, and just letting help and jupyterhub figure things out, we have a much easier tool to maintain. |
|
still remaining TODO:
|
|
Fwiw, if the admin doesn't specify them, the chart falls back to defaults. https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/main/images/singleuser-sample/README.md |
odd, it failed to launch a notebook for me when i tried this, but the possibility of PEBKAC exists. i'll try again... |
yep. PEBKAC. it's indeed using the default/sample image. i will still check for this as it's not exactly the behavior that we want. |
hubploy.yaml and use the default z2jh method
…dev work will be focused on this version moving foward
resolves #126
now, you can specify an image in either/both
staging.yamlandprod.yamlto specify an image to run in that environment (stagingorprod). this will override any image spec defined incommon.yaml.example:
here's the order of presidence for how the image/tag will be set:
prodorstaging.yaml, that will be used.common.yamldoing it this way allows us to remove nearly all of the convoluted logic around specifying the image! our CI/CD will need to be updated to use the new image hash, but that's pretty straightforward.
this is still a WIP, as there are some config parsing weirdnesses that i need to think about. specifically, if there is both noimages:stanza inhubploy.yaml, andjupyterhub.singleuser.imageinstaging/prod.yaml, spawning in to the hub fails.i'll address this in a later commit.