Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter environments based on URL parameters #176

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jtpio
Copy link
Member

@jtpio jtpio commented Jul 7, 2020

This could partially fix plasmabio/tljh-repo2docker#29.

We discussed this in person with @pierrepo as a way to directly point a user to the right environment, via a link from outside JupyterHub.

The link would look like the following: https://hub.plasmabio.org/user-redirect/rstudio?environment-name=plasmabio-template-r

Giving it more thoughts, we should probably wait a bit before merging this in. To give it some time to really grasp the use case and make sure that having the two flows (with and without the environment name) is not confusing to the user.
Going the hub directly and selecting the environment would still use the default_url configured in the plugin, and not the one that a user could have used via a /user-redirect link.

However one advantage is that it could also make it easier to start using nbgitpuller if the author of the environment wants to. They would be able to construct URLs that would contain the link to the repo to pull with nbgitpuller, the name of the environment to start and optionally the URL to redirect to (/rstudio for RStudio).

Also a better approach will be to use the Spawner.options_from_query that will be added to jupyterhub==1.2:

https://github.com/jupyterhub/jupyterhub/blob/3d524f2092c8f1ca4c2953d78156b73107ef8c1c/jupyterhub/spawner.py#L387-L415

Here is an example of the user flow:

environment-name-query-parameter

  • Add documentation to show how to create such URLs

@jtpio
Copy link
Member Author

jtpio commented Jul 7, 2020

There could also be some edge cases where the user would leave the server (closing the tab) and come back to it later from the hub instead of using the link.

Or using the link a second time while a server is already running.

In the long run this could require making an extensive use of the named servers as discussed in #130.

@pierrepo
Copy link
Contributor

pierrepo commented Jul 7, 2020

Thanks @jtpio

Or using the link a second time while a server is already running.

Do you know what could happen in this case?

@jtpio
Copy link
Member Author

jtpio commented Jul 7, 2020

They would be redirected to the default server that is currently running.

If the running server is the same as the one they started with the link, then it should be fine.

If the running server is different (for example Python without RStudio) then they could get a 404 (/rstudio might not exist).

@pierrepo
Copy link
Contributor

pierrepo commented Jul 7, 2020

Ouch!

It could be a mess indeed.

@pierrepo
Copy link
Contributor

pierrepo commented Jul 7, 2020

They would be redirected to the default server that is currently running.

The name of the env should make as a filter and prevent this, no?

@jtpio
Copy link
Member Author

jtpio commented Jul 7, 2020

Then that means the default running server would have to be stopped, so a new one could be started? It sounds like it would be nicer to let the users (or the idle culler) stop their own servers to prevent data loss.

Also naming the servers automatically using the name of the environment (#130) would probably handle this case better.

And using the user_redirect_hook to redirect to the correct server from the /user-redirect link:

https://jupyterhub.readthedocs.io/en/stable/api/app.html?highlight=user_redirect_hook#jupyterhub.app.JupyterHub.user_redirect_hook

@pierrepo
Copy link
Contributor

pierrepo commented Jul 7, 2020

One question, probably stupid:

Could we stop a running server if the user closes the web browser window?

@jtpio
Copy link
Member Author

jtpio commented Jul 7, 2020

Could we stop a running server if the user closes the web browser window?

Technically: setting a small value for the idle culler could almost simulate this behavior

In practice: this would be disruptive to the user, especially if they use (or have used) Jupyter elsewhere

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Offer RStudio as default frontend for R users
2 participants