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

Starting with 6.1, I can't start terminals directly with a GET request #5790

Closed
santiagobasulto opened this issue Oct 2, 2020 · 7 comments · Fixed by #5813
Closed

Starting with 6.1, I can't start terminals directly with a GET request #5790

santiagobasulto opened this issue Oct 2, 2020 · 7 comments · Fixed by #5813

Comments

@santiagobasulto
Copy link

Hello. I am teaching a beginners Operating Systems class (explaining the very basics of Linux to young students). Up to version 6.0.3, I was able to direct my students to https://myserver.com:8888/terminals/1 and that'd immediately start a terminal for them.

Starting with 6.1 I can't do that, now it throws a 404. Did the API change and now it's necessary to somehow "create" the terminal before issuing the GET request? Is there any way to circumvent this?

Thanks!

@kevin-bates
Copy link
Member

Hi @santiagobasulto - this appears to have occurred with #4180. As you can see, there's some sentiment that this was a bug but, if I'm understanding the conversation, @rgbkrk suggested a named path that would possibly restore the "hidden" functionality.

Kyle - are you planning on contributing support for GET .../terminals/new?

Santiago - in the meantime, your students might be best off staying on 6.0.3.

@santiagobasulto
Copy link
Author

Oh wow! such a tiny piece of code was the source of all my troubles 😂. Thanks for your response @kevin-bates, I'll stick to 6.0.3 for now, but I think this is actually a great feature, specially to open several shells at the same time.

@cailiang9
Copy link

This feature is quite useful. Many people use it to indicate functions of some metric monitors, such as .../terminals/htop .../terminals/username .../terminals/nvidia-smi. Then start the command in the corresponding terminal page.
@kevin-bates @rgbkrk Any plans to re-open this useful feature?

@kevin-bates
Copy link
Member

Thanks for the comments @cailiang9 and @santiagobasulto. If possible, it would be helpful if you could take a look at #5813 and/or take it for a spin. It does introduce a slight change in behavior, but I think that's probably the compromise we're looking at.

@rgbkrk
Copy link
Member

rgbkrk commented Oct 15, 2020

are you planning on contributing support for GET .../terminals/new?

It ended up being less of a priority, so it's far down my backlog. If someone runs with it I don't mind. 😄

@rgbkrk
Copy link
Member

rgbkrk commented Oct 15, 2020

Oh whoops, I see you've opened the PR since I last had this tab open. Thank you @kevin-bates, I'll review it.

cmd-ntrf added a commit to ComputeCanada/puppet-jupyterhub that referenced this issue Oct 19, 2020
A regression was introduced in notebook 6.1.0 where it is no
longer possible to start a terminal by simply going to the url
"/terminals/1". A fix is currently underway, but until a new
version of notebook is released, we will settle for 6.0.3.

Related issue:
jupyter/notebook#5790

PR fixing this issue:
jupyter/notebook#5813
@santiagobasulto
Copy link
Author

Thanks folks!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants