Make spinning up multiple Jupyterlabs configurable

[aktech]

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 apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

Documentation

Access-centered content checklist

Text styling

• The content is written with plain language (where relevant).
• If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
• All links describe where they link to (for example, check the Nebari website).
• This content adheres to the Nebari style guides.

Non-text content

• All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
• If there are emojis, there are not more than three in a row.
• Don't use flashing GIFs or videos.
• If the content were to be read as plain text, it still makes sense, and no information is missing.

Any other comments?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
jhub-apps	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 4, 2024 3:39pm
jhub-apps-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 4, 2024 3:39pm

[krassowski]

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?

[aktech]

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.