Stricter rules for named servers

[minrk]

Problem Statement

As a JupyterHub user, when I create a named server, sometimes it just breaks depending on the name of the server I use. After talking to my admin, I understand better that I'm not allowed to use some characters (like capital letters in some places). I am ok with being restricted, but would like to have a clearer idea of what characters I can and can not use, and clear feedback when I use them.

As a JupyterHub developer, I need to take the 'server name' into account in many places. These being unrestricted fields means they must be escaped, truncated, normalized, etc. which is a source of bugs and complications, often because these are not very widely used. Server names come up in:

• server URLs
• resources like pod names, container names, etc.

If I could assume more about the server name, I wouldn't need to do so much work to handle them.

Proposed Solution

Restrict the server name to a simpler, url-safe name, guaranteeing that it can be used unmodified in many contexts. Servers may also have an unrestricted "display name" that can be used for UI purposes only. This will need to be done in a way. The name rules should require that server names are:

1. names are valid DNS labels
2. valid URL components
3. not empty
4. fit within a maximum length

Proposed Implementation

For migration purposes, we can migrate any existing server name to use the current name as the 'display name', and use a slugify scheme to generate a safe version and deal with collisions once. We can migrate existing servers with non-compliant names via one-time slugification without breaking anything except for a one-time change of the URL for a server with a given name. A new "display_name" property may be added in some APIs and fields to allow rendering a nicer name, but all API endpoints will exclusively operate on 'true' (safe) names.

How will this fit in the ecosystem?

Spawners and URL-building tools that interact with JupyterHub will be able to use server.name as-is in more places, reducing confusion and complications from using free strings in APIs and URLs.

Endorsements

• @manics has started work on Restrict named server servernames jupyterhub#5192
• @minrk supports this simplification in Breaking: Restrict servernames by default jupyterhub#5054

[kellyrowland]

Thanks for posting this - I totally agree with the changes and am writing to note that our deployment will be impacted.

Generally speaking, we use named servers of the format <system>-<setup>-<architecture> (dash-separated) with a few of the system names containing an underscore; this change will impact the server names which contain underscores since the underscore will no longer be a valid character in server names.

When a user lands on our home page, they are presented an array of buttons, and which buttons they see is based on which compute systems the user has access to and if they are in a group that has access to one of these underscore-system-name servers. What that looks like in our home.html template is constructing server names by joining appropriate system/setup/architectures with a dash character and then rendering a button for each server.

Since we'll no longer be able to use underscores in system names that get constructed into server names, we'll have to agree on some other delimiter that makes sense to use for these group-specific servers and make sure that everything still lines up as expected for the end user experience.

Is there an estimated timeline of when this would get released?

I should probably also link to roadmap item #3 here since this is not unrelated to how we currently use named servers versus what one might do with profiles instead.

[manics]

It's a breaking change so will hopefully be part of JupyterHub 6. Don't think we've got a date yet, but I'd expect we continue to support JupyterHub 5 for a bit after 6 is released.

[minrk]

while it's a breaking change, we should be able to upgrade server names in-place at upgrade time. Where that might cause a bigger user-facing problem that I'm not sure how much we can help with is if the server name is present in e.g. volume names or mount paths, since changing the name would change those values.