diff --git a/docs/source/changelog.md b/docs/source/changelog.md index dc66fbb9..c02422e9 100644 --- a/docs/source/changelog.md +++ b/docs/source/changelog.md @@ -20,8 +20,10 @@ whether it was through discussion, testing, documentation, or development. - Support TLS encryption and authentication of all internal communication. Spawners must implement `.move_certs` method to make certificates available 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`. + + ![named servers on the home page](./images/named-servers-home.png) - Authenticators can now expire and refresh authentication data by implementing `Authenticator.refresh_user(user)`. This allows things like OAuth data and access tokens to be refreshed. diff --git a/docs/source/images/named-servers-admin.png b/docs/source/images/named-servers-admin.png new file mode 100644 index 00000000..25e23d15 Binary files /dev/null and b/docs/source/images/named-servers-admin.png differ diff --git a/docs/source/images/named-servers-home.png b/docs/source/images/named-servers-home.png new file mode 100644 index 00000000..b55ac6cb Binary files /dev/null and b/docs/source/images/named-servers-home.png differ diff --git a/docs/source/reference/config-user-env.md b/docs/source/reference/config-user-env.md index f5964042..c085b106 100644 --- a/docs/source/reference/config-user-env.md +++ b/docs/source/reference/config-user-env.md @@ -120,7 +120,7 @@ sure are available, I can install their specs system-wide (in /usr/local) with: ``` -## Multi-user hosts vs. Containers +## Multi-user hosts vs. Containers There are two broad categories of user environments that depend on what Spawner you choose: @@ -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, home directories typically persist once they are created, so they are 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: + +![named servers on the home page](../images/named-servers-home.png) + +as well as the admin page: + +![named servers on the admin page](../images/named-servers-admin.png) + +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 +``` diff --git a/docs/source/reference/rest.md b/docs/source/reference/rest.md index a3c054e0..95e9ea8b 100644 --- a/docs/source/reference/rest.md +++ b/docs/source/reference/rest.md @@ -158,11 +158,6 @@ The same servers can be stopped by substituting `DELETE` for `POST` above. ### 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 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