search

berkeley-dsep-infra / hubploy

Toolkit to deploy many z2jh based JupyterHubs
BSD 3-Clause "New" or "Revised" License
17 stars 15 forks source link

Support multiple images #10

Open yuvipanda opened 5 years ago

yuvipanda commented 5 years ago

We currently only support a single image per deployment. We should support multiple images instead, and integrate that with kubespawner profiles somehow.

rabernat commented 5 years ago

I was thinking about something related in https://github.com/pangeo-data/dev.pangeo.io-deploy/issues/56.

For a production cluster, it seems important to have a certain level of persistence and versioning of the images. Like, if I am using a container named gcr.io/pangeo-181919/ocean-pangeo-io-notebook:327e7f6, I should always have the option to launch that same container, even if new ones come out. This allows to maintain long-term backwards compatibility.

An alternative would be to address this at the jupyter kernel level. This is how we do it on standard, non-cloud-based jupyterhubs. We just keep making new kernels, but don't delete the old ones.

salvis2 commented 4 years ago

Looks like this issue will get some newfound attention. So hubploy.yaml defines images as a top-level section of the configuration. It would be easy to change that to a map and have several entries.

The image building would probably need another parameter to figure out which image to build. It could also have an option to build all of them in order.

I'm guessing the harder part will be how to inject this into the JupyterHub config. @yuvipanda do you have some suggestions on how to fiddle with this? I'm seeing that hubploy currently defines the path jupyterhub.singleuser.image in class LocalImage of config.py. We could make a new class / extend that class to structure a map that is assigned as the value of the profileList.

We might also want to setup some way to pass in prebuilt Docker images that hubploy doesn't have to build but still needs to put in profileLIst.