-
Notifications
You must be signed in to change notification settings - Fork 12
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
Make spinning up multiple Jupyterlabs configurable #499
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
jhub_apps/config_utils.py
Outdated
allow_multiple_jupyterlab = Bool( | ||
False, | ||
help="Allow users to spinup multiple JupyterLab servers", | ||
).tag(config=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could improve naming here:
- I have not tried it but knowing the codebase, it feels like user could spin up multiple JupyterLab servers when this is
False
by using JupyterHub API directly (if named servers are not disabled) - I wonder if we should instead name the option based on security implications; unfortunately there are multiple implications here so a single boolean would not suffice; I am thinking about:
- a) "allow users to swap jupyterlab runtime" (potentially disabling system extensions)
- b) "allow users to share their entire filesystem"
We could have separate options for (a) and (b) though but these would require different implementation. If that is not desirable, we could name this option "allow_jupyterlab_framework" as this is what it does. Maybe even more broadly it should be allowed_frameworks
/blocked_frameworks
list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could improve naming here:
I agree with you. I was struggling to find a more apt name for this.
I have not tried it but knowing the codebase, it feels like user could spin up multiple JupyterLab servers when this is False by using JupyterHub API directly (if named servers are not disabled)
Yep, correct. We only disabled it from jhub-apps interface and jhub-apps service API.
I wonder if we should instead name the option based on security implications; unfortunately there are multiple implications here so a single boolean would not suffice; I am thinking about:
a) "allow users to swap jupyterlab runtime" (potentially disabling system extensions)
b) "allow users to share their entire filesystem"
Since it's an implication rather than the feature, I am not very confident on naming it like that. Although documentation would be an excellent place for this, wdyt?
If that is not desirable, we could name this option "allow_jupyterlab_framework" as this is what it does. Maybe even more broadly it should be allowed_frameworks/blocked_frameworks list?
I like both. allow_jupyterlab_framework
is the name I was actually looking for.
Maybe even more broadly it should be allowed_frameworks/blocked_frameworks list?
This would be nicer indeed with more flexibility. I prefer that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although documentation would be an excellent place for this, wdyt?
Agreed
acd1366
to
11b5e31
Compare
Here are the rendered docs: https://jhub-apps-docs-git-make-multiple-jlab-optional-nebari-jhub-apps.vercel.app/docs/configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @aktech, looks good to me now!
Reference Issues or PRs
Fixes #498
Nebari PR for overriding this from nebari config:
nebari-dev/nebari#2754
What does this implement/fix?
Put a
x
in the boxes that applyTesting
Documentation
Access-centered content checklist
Text styling
H1
or#
in markdown).Non-text content
Any other comments?