mirror of
https://github.com/jupyterhub/jupyterhub.git
synced 2025-10-18 15:33:02 +00:00
documentation for named server UI
This commit is contained in:
@@ -20,8 +20,10 @@ whether it was through discussion, testing, documentation, or development.
|
|||||||
- Support TLS encryption and authentication of all internal communication.
|
- Support TLS encryption and authentication of all internal communication.
|
||||||
Spawners must implement `.move_certs` method to make certificates available
|
Spawners must implement `.move_certs` method to make certificates available
|
||||||
to the notebook server if it is not local to the Hub.
|
to the notebook server if it is not local to the Hub.
|
||||||
- There is now full UI support for managing named servers (TODO: screenshot).
|
- There is now full UI support for managing named servers.
|
||||||
With named servers, each jupyterhub user may have access to more than one named server. For example, a professor may access a server named `research` and another named `teaching`.
|
With named servers, each jupyterhub user may have access to more than one named server. For example, a professor may access a server named `research` and another named `teaching`.
|
||||||
|
|
||||||
|

|
||||||
- Authenticators can now expire and refresh authentication data by implementing
|
- Authenticators can now expire and refresh authentication data by implementing
|
||||||
`Authenticator.refresh_user(user)`.
|
`Authenticator.refresh_user(user)`.
|
||||||
This allows things like OAuth data and access tokens to be refreshed.
|
This allows things like OAuth data and access tokens to be refreshed.
|
||||||
|
BIN
docs/source/images/named-servers-admin.png
Normal file
BIN
docs/source/images/named-servers-admin.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 104 KiB |
BIN
docs/source/images/named-servers-home.png
Normal file
BIN
docs/source/images/named-servers-home.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 103 KiB |
@@ -145,3 +145,37 @@ In both cases, you want to *avoid putting configuration in user home
|
|||||||
directories* because users can change those configuration settings. Also,
|
directories* because users can change those configuration settings. Also,
|
||||||
home directories typically persist once they are created, so they are
|
home directories typically persist once they are created, so they are
|
||||||
difficult for admins to update later.
|
difficult for admins to update later.
|
||||||
|
|
||||||
|
## Named servers
|
||||||
|
|
||||||
|
By default, in a JupyterHub deployment each user has exactly one server.
|
||||||
|
|
||||||
|
JupyterHub can, however, have multiple servers per user.
|
||||||
|
This is most useful in deployments where users can configure the environment
|
||||||
|
in which their server will start (e.g. resource requests on an HPC cluster),
|
||||||
|
so that a given user can have multiple configurations running at the same time,
|
||||||
|
without having to stop and restart their one server.
|
||||||
|
|
||||||
|
To allow named servers:
|
||||||
|
|
||||||
|
```python
|
||||||
|
c.JupyterHub.allow_named_servers = True
|
||||||
|
```
|
||||||
|
|
||||||
|
Named servers were implemented in the REST API in JupyterHub 0.8,
|
||||||
|
and JupyterHub 1.0 introduces UI for managing named servers via the user home page:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
as well as the admin page:
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Named servers can be accessed, created, started, stopped, and deleted
|
||||||
|
from these pages. Activity tracking is now per-server as well.
|
||||||
|
|
||||||
|
The number of named servers per user can be limited by setting
|
||||||
|
|
||||||
|
```python
|
||||||
|
c.JupyterHub.named_server_limit_per_user = 5
|
||||||
|
```
|
||||||
|
@@ -158,11 +158,6 @@ The same servers can be stopped by substituting `DELETE` for `POST` above.
|
|||||||
|
|
||||||
### Some caveats for using named-servers
|
### Some caveats for using named-servers
|
||||||
|
|
||||||
The named-server capabilities are not fully implemented for JupyterHub as yet.
|
|
||||||
While it's possible to start/stop a server via the API, the UI on the
|
|
||||||
JupyterHub control-panel has not been implemented, and so it may not be obvious
|
|
||||||
to those viewing the panel that a named-server may be running for a given user.
|
|
||||||
|
|
||||||
For named-servers via the API to work, the spawner used to spawn these servers
|
For named-servers via the API to work, the spawner used to spawn these servers
|
||||||
will need to be able to handle the case of multiple servers per user and ensure
|
will need to be able to handle the case of multiple servers per user and ensure
|
||||||
uniqueness of names, particularly if servers are spawned via docker containers
|
uniqueness of names, particularly if servers are spawned via docker containers
|
||||||
|
Reference in New Issue
Block a user