[enhancement] - Use conda-store for all environments

[leej3]

Description

The idea here would be to remove the conda install/environment from the docker image(s).

Suggestion

Currently the environment that launches the jupyterlab environment is defined as part of the docker image that is used for user pods. The advantage here is that we define a tricky set of dependencies that need to be in the environment that launches the jupyterlab server. Plotly is a good example... the labextension does not work unless installed into this environment even though it has implemented the jupyterlab 3.0 approach to packaging these extensions.

A downside of managing the jupyter server launching environment as part of the docker image is reduced flexibility for the end user. Currently, if using the default images in a deployment an end user must wait for the images to be updated and pushed before they can redeploy and avail of the fix.

The fix proposed here is to launch the jupyter server from an environment provided by conda-store. To do this we need to make sure the conda-store nfs mount is available and that the appropriate environment for launching the jupyterlab server is available (it may take a while upon redeployment).

A few things to think about regarding implementation:

• This could result in a mess if the environment is not available in the conda store or is "broken" (by some definition). It's likely that although we want to make this core environment modifiable from the qhub-config.yaml we need to have some checks to ensure a functioning server (certain packages, package versions etc). Perhaps part of the schema?
• Coordination with the environments of the dask cluster and perhaps other integrations may be problematic... or perhaps make it easier... I don't know
• This would drop the size of the docker images substantially which is currently a significant cause of slowdown in launching servers for users.

[viniciusdc]

Hi @leej3 thanks for opening this issue, we will be discussing this soon.

[kcpevey]

I just realized that for one of our projects we had been updating the qhub version so that we were on 0.3.12 but forgot to update the qhub-dask pin and were way behind on that. Implementing the above would help with this.

[costrouc]

Blocked by https://github.com/Quansight/conda-store/projects/1. Will be solved by 0.3.0 release. Check then.

[github-actions]

This issue has been automatically marked as stale because there was no recent activity in 60 days. Remove the stale label or add a comment, otherwise, this issue will automatically be closed in 7 days if no further activity occurs.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.

[iameskild]

I believe this still a great feature to consider!

[trallard]

@iameskild @viniciusdc is this still relevant? are we now not managing the envs with conda-store by default?

[iameskild]

Hi @trallard I believe this outlines a possible solution that allow us to avoid having conda env/packages baked into the Jupyterlab Docker image (ie this env) and encourages us to use conda-store instead.
The potential limitation is that I'm not sure this solution will be able to serve apt packages and similar; this issue does attempt to handle both but is likely a lot heavier of a lift.
I feel fine closing this since we are tracking the idea / sentiment elsewhere, I'll let you make the call :)

[trallard]

Ahhhh - that was it!
The main caveat with this approach is not only the apt availability but the fact that to enable this pattern we'd need elevated permissions within the pod (i.e. root) which is not ideal from a security POV.

I will close this issue as I think indeed we can better handle Docker + end-users envs in better ways, as well as updating dependencies and security updates.