---
# System prepended metadata

title: Scivision - Hub23 chat 25/05/22

---

# Scivision - Hub23 chat 25/05/22


Use case:
- each of the three post-docs hve sample notebooks. These are online in the form of binder links. These take a long time to spin up. 


Jupyterhub:
- method to divvy up compute when jupyter is the interface.
    - Q. Can you use any interface? 
        - come via jupyter plugin python packages.
- Two different distributions of jupyterhub - 1) scalable, 2) littlest jupyterhub, single machine.
- Uses:
    - active work. researchers.
- features:
    - home dir
    - persistent
    - shared directories
    - pre-defined environments. containers. packages installed here aren't necessary kept. 

Binderhub:
- jupyterhub + dynamic computational environment.
- repo2docker + proxy serve to redirect user to mybinder/url. 
- Uses:
    - interactive tutorials
    - scientific comms
    - reproducible papers
    - interactive docs
    - docs.
- Features:
    - dynamic env generation
    - generated URLs for easy sharing
    - ephemeral. 



The only thing that is useful for researchers from binderhub is the dynamic environment generation. 

Future work: bringing `persistent binderhub` which is repo2docker functionality in Jupyterhub. 

This will be a feature flag to jupyterhub. 

Binder is slow because it is building a docker image. But even just one commit will cause it to build again. `nbgitpuller` is a way round this because you technically. have a separate binder branch that has a separate binder link and use nbgitpuller to pull from master. Binder only builds then when there are new commits into the binder branch. 
alejandro - is `.binder` enough to do avoid a reset? No. it will still rebuild if there is a commit on your branch.
there is a `repo2docker` action.

binder is also slow because of the federation redirector:
    - checks if novel repo
    - if yes, where did I build it lst time, send it there.
    - also what is the load of clusters.
    - members do not share a container registry. 
    - you're also limited at the kubernetes level.
        - pods need provisions
        - if nodes are full time taken to provide new nodes.

- workshops hub23 on jupyerhub. 
- repo2docker will work with a hub. 
- you can spin up a new hub23.
- **Requirementsx for a new Hub**
    - What GPU/CPU is needed? 
    - What software? 
    - 2i2c. 
    - Dask/xarray is not currently available on Hub23. Not part of the roadmap, but could be.