Custom resource requests

[jhamman]

In the monthly Binderhub/Jupyterhub call today, I brought up the concept of custom resource requests in the binderhub framework. A few use cases came up and we briefly discussed at least two approaches for addressing this topic.

Use-cases

1. Specify CPU/memory requests: Some applications will want/require more resources than others.
2. Specify other resources: Some applications may be able to take advantage of GPUs or some other "resource" that can be included in a kubernetes pod.

Approaches

Two high-level approaches have been discussed:

1. Single-user kubernetes resources are provided in the repository. This could take the form of a config file in the ./binder directory. This config would be passed on to the kubernetes request for the user pod. For example:

# binder_config.yaml
    singleuser:
      cpu:
        limit: 8
        guarantee: 1
      memory:
        limit: 26G
        guarantee: 4G

2. A binderhub REST-like API. Currently, binderhub passes parameters through to the user session using a pretty simple REST-like API. For example: https://mybinder.org/v2/gh/dask/dask-examples/master?urlpath=lab where the ?urlpath=lab is some special request. You could imaging a API and UI that basically extend this to include other things: https://mybinder.org/v2/gh/dask/dask-examples/master?urlpath=lab&cpu=8&memory=26G&GPU=8

The main distinction between these two points is that one lives in the repo, whilst the olther is configured by the user of a binder at a specific time.

cc @minrk @choldgraf @betatim @jzf2101 @yuvipanda @craig-willis

[jzf2101]

As an aside I've seen more requests for item 2 than item 1 though both are important.

[yuvipanda]

Thanks for opening this issue, @jhamman.

I think we should do (2), since resources are a runtime parameter (rather than a build time one). We can probably suggest / populate defaults from the repo at some point, but that's probably a separate issue.

[betatim]

I think making resource requests runtime parameters (I think this is what you call option 2) is a good place to start. It lets the creator of the repository set a "default" via the link they give out/place in their badge.

Specifying it inside the repository is a bit tricky because it means BinderHub would have to clone a repository to look inside it to find the file that might specify resource requests. (This has been discussed a few times before and so far the consensus is that we don't want to start looking inside repositories)

There is also #712 about naming of URL parameters, including ones that not all BinderHubs support.

[jhamman]

Thanks all. I think we should focus this conversation on #712 for now. I'll revive that conversation and we can go from there.