Support multiple images

[yuvipanda]

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

[rabernat]

I was thinking about something related in pangeo-data/pangeo-cloud-federation#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]

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.