Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Embed wrapspawner to allow selection of image #545

Closed
gsemet opened this issue Feb 28, 2018 · 9 comments
Closed

Embed wrapspawner to allow selection of image #545

gsemet opened this issue Feb 28, 2018 · 9 comments

Comments

@gsemet
Copy link
Contributor

gsemet commented Feb 28, 2018

Hello

How hard would it be to embed wrapspawner or similar in order to allow user selection of desired profile upon connection.
What I mean by "profile" is a predefined list of "image + cpu number + disk space + memory".

I imagine something like a dropbox where user can select for instance"small datascience notebook", "big memory datascience" or "Python training notebook", and so on, and it would launch the related image and cpu/memory request for kube.

@yuvipanda
Copy link
Collaborator

Thank you for opening this issue, @gsemet! I agree that it would be very useful to have!

I think adding something like jupyterhub/dockerspawner#219 to github.com/jupyterhub/kubespawner is a better fit! What do you think, @minrk?

@cam72cam
Copy link
Contributor

I'd like to help out, even if that is just being a guinea pig on this ticket

@gsemet
Copy link
Contributor Author

gsemet commented Feb 28, 2018

Isn’t it easier or better to integrate wrapperspawner in zero to jupyterhub or hack into kubespawner?

@gsemet
Copy link
Contributor Author

gsemet commented Mar 1, 2018

@yuvipanda If I follow you proposal to hack into kubewrapper, I would like to propose the following change in kubewrapper:

  • New option c.KubeSpawner.single_user_profile_list is added and take precedence over `singleuser_image_spec
  • this option is a list of dictionnary of form:
{
    'display_name': 'Human Readable Profile Title',
    'image_spec': 'image/to_execute:label'
    'cpu_limit': cpu_limit,
    'cpu_guarantee': cpu_guarantee,
    'mem_limit': mem_limit,
    'mem_guarantee': mem_guarantee,
    'lifecycle_hooks': lifecycle_hooks,
    'volume_mounts': volume_mounts,
}

Note that lifecycle_hooks and volume_mounts can be superseeded in this configuration (I propose the following: if key is defined, no matter its value (None or set to a value), the setting is super seeded. If not set, the default value stays c.KubeSpawner.volume_mounts for example).

Or maybe we can be more agressive:

  • the format is not defined (except the mandatory 'display_name'), and any KubeSpawner parameter can be superseeded in this data structure.

This would allow extension in the future, such as adding a logo (base64 or url or image id) to have a better looking profile selection (like the welcome panel in jupyterlab).

@minrk
Copy link
Member

minrk commented Mar 2, 2018

indeed, adding wrapperspawner support may be the best way to go.

@gsemet
Copy link
Contributor Author

gsemet commented Mar 2, 2018

I have made a proposal in this PR: jupyterhub/kubespawner#137

@jgerardsimcock
Copy link

Has this functionality been merged into the z2jh deployment yet? If not and we want to implement this, what is the best way to approach this?

@minrk
Copy link
Member

minrk commented Jun 4, 2018

I think the kubespawner profiles are now in z2jh

@consideRatio
Copy link
Member

Closed thanks to @gsemet's work on jupyterhub/kubespawner#137!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants