jupyterhub
Select pod resources from binder UI
In the last few weeks, a number of folks have asked for specific resources for specific binders. Examples of these requests are:
- can I have a pod with a GPU in it?
- can I have a pod with extra memory or CPU?
Kubespawner currently has this functionality through the use of a profile_list.
I'm curious if this is in scope for BinderHub and, if so, what the API would be. I'm imagining a dropdown in the UI that provides the equivalent of the Kubespawner profile list.
There have been previous discussion on this and one of the questions that keeps coming up is: should the launcher or the creator of a repo control the resource request? What should happen if the request can't be satisfied ("recommended resources" vs "required resources")?
From a technical point of view having the repository (the creator) specify it is tricky because it means BinderHub needs to clone the repository in order to find out.
Part of the reason for #712 is that I want to be able to specify resource requests as part of the launch link.
It would be great if you could drive this discussion forwards so that it gets to a point where we have a concrete suggestion to implement that does what people would like it to do.
Yes, I was also thinking about this problem in these terms. Not to make this more complicated but I think there are three options here.
- Creator of binder repository prescribes resources. This would look something like the singleuser section in the jupyterhub chart:
singleuser:
# start jupyter notebook
cmd: jupyter-lab
cloudMetadata:
enabled: true
cpu:
limit: 4
guarantee: 1
memory:
limit: 26G
guarantee: 4G
nodeSelector:
cloud.google.com/gke-nodepool: user-pool
Of course, this is more complicated than most users would like to see but it would allow for significant customization. 2. User selects from a set of preordained resource packages. This would look like the functionality that kubespawner profile_list provides. You might imagine allowing something like what I have below in the binderhub chart:
{
'display_name': 'Base Env',
'default': True,
'spawner_override': {
'cpu_limit': 1,
'mem_limit': '512M',
}
'display_name': 'Big Memory Env',
'spawner_override': {
'cpu_limit': 48,
'mem_limit': '96G',
}
}, {
'display_name': 'GPU 2 Env',
'spawner_override': {
'cpu_limit': 48,
'mem_limit': '96G',
'extra_resource_guarantees': {"nvidia.com/gpu": "2"},
}
}
- Finally, a more flexible REST-like API could expose these options to the user and the Binder UI could provide options for a bunch of options. This follows #712.
My personal thought, without having gone through the step of truly scoping the work, is that (2) is going to be fairly easy and accomplish most of what we will ever need. I agree that (1) will be hard because the binder would need to be inspected before deploying. (3) also seems like a reasonable option but may expose much more flexibility than is really needed.
Is there an update on this? Both 1. and 2. would be useful, but 2. would be enough for what we need.
@rochaporto - I don't think anyone has immediate plans to work on this. Without speaking for the binder team, I assume contributions would be welcome.
We could give this a go if noone has picked it up. If there's ongoing work already please let us know.
