Managing multiple Jupyter servers

[lucbouchard1]

I'm starting this issue to talk about how the electron app will manage multiple Jupyter server connections. This includes both remote connections and servers that are already running locally when the application starts. I think there are two primary ways to approach this: either we provide a UI that appears before the JupyterLab frontend and allows selecting/adding a connection, or we create an extension for JupyterLab that manages connections after the app has started.

1) Independent Server Management UI

This UI would appear before the splash screen and would allow the user to choose between spawning a new local server, connecting to a local server that's already running, or connecting to a remote server. If the user selects to create a new local server, the splash screen is displayed until the server starts.

Pros

• We don't need to to start a local server if the user wants to use a server that is already running.

Cons

• The user has to do something every time the app starts, which can slow down workflow and be confusing for new users.
• We would need to restart the app in order to change connections.
• We would need to develop a UI from scratch that is independent of JupyterLab.

2) JupyterLab Server Management Extension

This option requires that we spawn a Jupyter server when the electron app starts, because, as far as I know, the JupyterLab frontend needs a server connection to start properly. The UI would provide a list of currently running local servers and a list of previously used remote connections.

Pros

• We wouldn't need to restart the app in order to change the server connection.
• We wouldn't need to start from scratch on a UI design.

Cons

• We always need to start a Jupyter server when the application starts, even if the user plans to use a remote connection.

Analysis

There are, of course, slight deviations from these two options. For example, we could do a hybrid of the two where the user can manage connections after choosing an initial connection to start on. However, I think these are a good starting place.

I think option 2 makes the most sense, as it makes the startup process really smooth and allows the user to start working immediately.

[ddavidebor]

I think most users of this app will not be interested in getting to work straight away, something that can be accomplished with anaconda itself, but to access remote environments (cloud VMs, remote servers, computing clusters, linux from windows etc etc).

In fact i would not expect the user of this app to have a working jupyter enviroment at all, especially on windows.

I don't know if jupyterlab can handle a no-connection state (it does not get initialized? i dunno). but it handles well a disconnection.

The most elegant option could be manage this from jupyterlab itself, with a nice UI similar to the new UI to select the kernel/console/editor. But we would either:

• re-initialize all plugins
• reload the page

I think we can narrow down the cons of option 1, for example:

We would need to restart the app in order to change connections.

We could simply use different html pages, one for jupyterlab and one for the notebook selection UI.
This would be a very robust solution to implement.

We would need to develop a UI from scratch that is independent of JupyterLab.

The UI would probably end up the classic add/move/edit/delete/select a list of items, each with it's own options. in that case we could find some open source UI with a compatible license to work from.

Also check #15 out.

[ddavidebor]

@blink1073 do you think it would be possible (and reasonable) to start jupyterlab without a jupyter server for the sole purpose of displaying a UI (similar to the select kernel/editor/terminal/console) for selecting the server to the user, and then either re-initialize it or refresh the page?

[blink1073]

You could also start a separate app that is the server picker, and then launch the main jlab app. I think picking a server is a good enough reason to refresh the page either way.

[ddavidebor]

That's a great idea. Spawning jupyterlab apps from the main process (used to select the server) would also allow the user to connect to different servers at the same time with no added complexity.

[lucbouchard1]

I'm starting to think that the best solution is a hybrid of the two that works as follows:

• If the user has Jupyter/Python installed, the app, by default, launches a local Jupyter server. There will be a server management pane in the sidebar that will allow users to select/add/edit/remove remote connections.
• If the user does not have Jupyter/Python installed, an html page appears in the application window that has a div instructing the user to install Python/Jupyter in addition to a server selection UI. The "Install Jupyter" div should be removable (persistently) in case the user is only using the app for remote connections and doesn't want to install Jupyter/Python on their machine.
• Include a setting that allows the user to prevent a local Jupyter server from starting. Instead, the html page described above would appear, allowing users to select between remote connections.

---

This design covers the use cases mentioned in this thread, which I think boil down to this:

1. New users who are unsure how to get everything working.
2. Intermediate/experienced users who just want a better JupyterLab experience by moving it out of the browser.
3. Intermediate/experienced users who primarily work with remote connections and may or may not have Jupyter/Python installed.

For 1 and 2, we would be preserving an uninterrupted startup that will improve workflow. For 3, we are allowing quickly connecting to any number of remote connections. For 1, we are making it easier to get JupyterLab working. JupyterLab will always be launched with a server connection, and switching between servers will trigger a page refresh. @ellisonbg @cameronoelsen thoughts on this?

[lucbouchard1]

Here is the design we've decided on:

• For a user with Python/Jupyter installed, the electron app will, by default, launch a local server and immediately open JupyterLab. There will be a command/menu button to connect to a new server, which will launch a new window that displays a server management UI separate from JupyterLab. When the user chooses their connection, the server management UI is replaced by JupyterLab. Thus, all connections are in separate windows.
• For a user without Python/Jupyter installed, a window will appear that allows the user to either a) learn how to install Jupyter or b) connect to a remote server using the server management UI described above.
• After the initial launch, we will recreate the previous window configuration. Thus if the user last had a remote connection open, we will reopen that connection.

The server management UI is going to be written using React.

[lukelbd]

It looks like a simple server management system was implemented by PR #71, but in v3.3.2-1 I don't see the "Servers" menu option mentioned in the #71 thread? Was this once a feature that has been lost, or was it never completed?

There are a couple other open threads requesting this feature (#15 and #394).

[jrmoserbaltimore]

Would this be an appropriate place to raise integration with mamba_gator? I think that's a separate issue; but instantiating multiple conda environments and running JupyterLab within them would create multiple servers the application then would need to deal with somehow. Maybe I should raise this as a separate issue and reference this issue as related?

[mbektas]

this is already implemented