Allow users to bring a container image

[yarikoptic]

FWIW it is somewhat possible already: IIRC docker was ran in --privileged mode and that allows nesting singularity calls within, so people could bring/use their containers on the hub. What exactly do you mean in this issue - feature parity with that or some other "new" aspect?

[aaronkanzer]

Cc @satra @yarikoptic

Was chatting yesterday with @kabilar -- what exactly do users look to "bring" with their own container image?

Is it purely just a different set of dependencies? Or something more specific?

[asmacdo]

@yarikoptic IIUC this request was not about running some container inside a jupyterhub instance, but rather that a user could provide an alternative jupyterhub image to the single-user image we provide

[satra]

it may be good to update the original description with some use cases. part of the reason to update the hub is to use the potential new offering in jupyterhub that integrates binder like possibilities. if people could instantiate the image with their repo, that could be a way to bring their own image.

[asmacdo]

Assuming this feature request is that users would like to specify a user-hub container image at user-hub launch time, this feature is not available (afaict) for the helm chart (which is used by both the current ansible deployment and the do-eks branch)

Jupyterhub user instances are created via a user interaction with a jupyterhub server. We can configure these instances to be whatever strings we want at our infrastructure deployment time, but AFAIK there isn't a way to set this at user-hub deployment time based on user input, but we could file an issue upstream. https://github.com/jupyterhub/zero-to-jupyterhub-k8s

I think we could work around this, but admins would need to create a new set of profiles with other image options. So, this option doesn't scale, but can be done if necessary.

[satra]

see the post in this issue: https://github.com/dandi/dandi-hub/issues/121

i don't know what the key differences are between this issue and that one.

[asmacdo]

Summarizing to check my understanding --

The idea is to use https://github.com/yuvipanda/jupyterhub-fancy-profiles to extend the config options of jupyterhub. This would allow users to specify the image that runs.

The 2i2c interface allows users to specify their image by repo/image:tag, or by specifying a git repository and building the image on the fly.

That solution would also fix #121

It's not clear to me how "must have jupyterhub installed" is enforced, or if this an interface that allows the deployment of -any- image (not just a variant on a user-jupyterhub) into our kubernetes cluster? We will need to think through security concerns carefully.

[kabilar]

Thanks team. Apologize for the confusion. Was just porting over our requirements to GitHub Issues so I didn't have a chance to describe the use cases here. In terms of timeline, I was thinking that we could tackle this feature after the current DoEKS sprint which is working towards creating feature parity with the current ansible implementation.

@asmacdo Your description and the 2i2c interface is exactly what I had in mind. I broke this up into "bring your own image" and "build your own image", because I often find that rebuilding an image runs into issues. Although packages are defined in the requirements.txt (or setup.py, etc.) and the Dockerfile, months after the initial configuration dependency conflicts arise since all packages are not version locked and thus images cannot build (or if they build, packages cannot be imported). So I thought it would be useful to give users both options.