You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 17, 2023. It is now read-only.
Currently, the main profile menu at the top of the spawner is driven by container images it finds out on the cluster. This works reasonably well but it has a couple disadvantages.
it isn't intuitive for users to conceptualize the profiles by image
in order to provide users with multiple options, I had to create several container images that were all identical except for the name, so that I could "hang" different spark size profiles (and env vars, etc) from them.
I believe a cleaner organization would be to simply declare the profiles in the configmap by a name (for example, "Jupyter with Large Spark Cluster"), and then the actual jupyter image is just another property of the profile, it isn't driving the menu choices per se. For example in this scheme, I would generate a single cusomized jupyter image, and it would be the same value under all the profiles. The profiles would differ only in terms of the configuration of spark cluster size (or other service configurations, etc).
The text was updated successfully, but these errors were encountered:
LaVLaS
added a commit
to LaVLaS/jupyterhub-singleuser-profiles
that referenced
this issue
Jul 20, 2021
Currently, the main profile menu at the top of the spawner is driven by container images it finds out on the cluster. This works reasonably well but it has a couple disadvantages.
I believe a cleaner organization would be to simply declare the profiles in the configmap by a name (for example, "Jupyter with Large Spark Cluster"), and then the actual jupyter image is just another property of the profile, it isn't driving the menu choices per se. For example in this scheme, I would generate a single cusomized jupyter image, and it would be the same value under all the profiles. The profiles would differ only in terms of the configuration of spark cluster size (or other service configurations, etc).
The text was updated successfully, but these errors were encountered: