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

Hostname in link printed to access the notebook server #325

Closed
betatim opened this issue Jun 7, 2018 · 13 comments
Closed

Hostname in link printed to access the notebook server #325

betatim opened this issue Jun 7, 2018 · 13 comments

Comments

@betatim
Copy link
Member

betatim commented Jun 7, 2018

Seems like when we switch to notebook 5.5 the link printed in the output will no longer work for people. See for example jupyter/docker-stacks#642

Two questions:

  • what is our policy for bumping versions on things like the notebook?
  • should we hardcode the --hostname argument to docker in repo2docker to be localhost or 0.0.0.0 or something else entirely?
@AaronWatters
Copy link
Contributor

+1

Following the instructions does not work:

  
    Copy/paste this URL into your browser when you connect for the first time,
    to login with a token:
        http://ca10c819e280:62267/?token=e55a7...

There is no such server ca10c819e280 -- the user needs to manually change it to
"localhost" to make it work.

@choldgraf
Copy link
Member

I'm +1 on bumping versions to latest as long as it doesn't break things. I guess in this case we should just make the localhost hardcoded in there. Any idea why the notebook isn't using localhost by default anymore?

@betatim
Copy link
Member Author

betatim commented Jun 11, 2018

It used to/currently print http://0.0.0.0:62267/?token=e55a7.... Don't know why this changed but my guess would be that for most uses cases printing the hostname of the interface is nicer for users than printing an IP address.

Instead of hard-coding things I'd check if we can turn off this behaviour via a flag.

@AaronWatters
Copy link
Contributor

Is there any sort of work around for this? I'm working with biologists for example here
https://github.com/flatironinstitute/FREYA/tree/master/DataAnalysis and it's hard enough
to get them to paste an URL -- if I ask them to paste and then edit an URL they will...
not be happy.

@betatim
Copy link
Member Author

betatim commented Jun 13, 2018

I think with the default version of the notebook (v5.4) that repo2docker uses this does not happen. So my recommendation would be to stick with that instead of using the newer notebook v5.5

The way to move this forward is to help get this discussion to a point where there is consensus on how to handle this (configuration in the notebook or hardcoded command line argument or ...).

@choldgraf
Copy link
Member

is this something that either @takluyver or @minrk have insight on?

@takluyver
Copy link
Member

There's work underway to make the address it prints configurable: jupyter/notebook#3668

What it printed before was right by coincidence, but with Docker it's a coincidence that comes up quite reliably, so this change has upset a few people.

@willingc
Copy link
Contributor

Thanks @takluyver.

I agree with @AaronWatters that we should strive for a solution that has minimal impact on the end user.

@AaronWatters
Copy link
Contributor

Thanks @betatim -- I can confirm that the problem doesn't occur if i use

pip3 install --no-cache-dir notebook==5.4.1 

@betatim
Copy link
Member Author

betatim commented Jun 13, 2018

From jupyter/notebook#3668 it looks like there will be a configuration option for this in notebook in the next release of the notebook.

Currently repo2docker uses notebook v5.4 so we aren't yet impacted by this. I'd suggest we don't update the default version of the notebook to v5.5 and wait till jupyter/notebook#3668 has been merged and released. Then go straight for that version with the appropriate configuration set in the default command repo2docker executes.

@minrk
Copy link
Member

minrk commented Jun 14, 2018

What it printed before was right sometimes by coincidence - if using something like docker-machine, or mapping any port other than the internal one, e.g. docker run --rm -it -P 8888 jupyter/base-notebook, then it would be wrong and the container has no way of knowing what the right answer for host or port is unless it is explicitly told from outside.

@choldgraf
Copy link
Member

I'm +1 on holding off updating the notebook until we know this issue is resolvable

@AaronWatters
Copy link
Contributor

In that case I'd be in favor of some sort of a solution where the host and port is decided "from the outside" and passed in to the container somehow (env vars?) and those passed in values are printed out when the server reports the connection URL. Sadly, I don't know the details on how to implement this, but I suspect it should be possible, maybe as some sort of a wrapper to docker run?

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

No branches or pull requests

6 participants