[enhancement] Create a Demo deployment option for quickly trying out qhub

[Adam-D-Lewis]

Have a demo deployment option for trying out qhub

• deploy with nothing more than pip install qhub && qhub --demo
• works on Linux, MacOS?, Windows?
• downloads minikube, docker, launches a local qhub, opens to an instruction notebook
• includes notebooks demonstrating the features of qhub
  • dask
  • collaborative work
  • prefect
  • mlflow
  • etc.

[Adam-D-Lewis]

Suraj suggests k3d for setting up metalLB.

[Adam-D-Lewis]

Chris brought up the solution to this issue could potentially also be a good testing tool for us.

[Adam-D-Lewis]

Thinking about how to make this cross-platform. The following will need to be cross-platform.

• local k8s cluster provider
  • minikube, k3d, etc.
• terraform
• qhub

All of these are nominally cross platform, I believe.

The alternative is to use a vm on other machines and bring up qhub within the vm and port forward out the relevant ports for jupyterlab, grafana, etc.

So I guess this comes down to is it easier to run vm software (vagrant) cross platform or is it easier to run minikube, terraform and qhub cross platform.

Pros/Cons of Using VM

Pros

• simpler to get vagrant working on various OS's than getting minikube, terraform, and qhub to work on various OS's

Cons

• Requires more resources (qhub currently requires 4 GB RAM, and 2 cores)
• Longer qhub setup time might be required to download vdi (only ~1.6 GB larger (raw ubuntu size) than what otherwise would need to be done) which would reduce user experience

Leaning towards the VM since it seems simpler to maintain and control the user's experience without too many downsides.

[Adam-D-Lewis]

Also, I need access to a windows and macOS machine at some point in order to ensure this is cross platform.

Update: I can get a windows development box running for windows my windows testing. Quansight is considering getting a mac mini for testing/dev on MacOS.

[Adam-D-Lewis]

After talking with the team, there are some other benefits of not using a VM. One being that our tests could use this command. If we do a VM, we can't use this for our tests. Also, the VM resource usage will likely need to be 8 GB of RAM and 4 cores in order to use it which is a bit higher than I thought before.

After talking, I'll pursue this moving forwards NOT using a VM.

[Adam-D-Lewis]

Progress: I got a windows development box running by downloading the virtualbox windows vm from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/. I couldn't get wsl working on it, but I should be okay without it.

[magsol]

Looks like k3s on a single node behaves as both server and agent, so this (in theory) should be a viable option for single-node demo options.

k3d is maintained by Rancher (the group that created and maintains k3s) so chances are high that if k3s works, k3d will too.

[magsol]

At the very least, this seems like something we might able to automate with GitHub Actions: https://github.com/nolar/setup-k3d-k3s

[iameskild]

This sounds like a local deployment. Closing this for now. @Adam-D-Lewis if you had something else in mind, free feel to reopen this.