Docker Launcher - wrong hostname output when running in a VM

[TylerJewell]

We print out the wrong hostname in the final line of the che-launcher output if it is running inside of a VM.

Reproduction Steps:

1: Launched CentOS 7.2 VM.

2: Disabled iptables / firewalld.

3: Installed Docker 1.11.2

4: docker run -v /var/run/docker.sock:/var/run/docker.sock \ -CHE_HOST_IP=192.168.56.110 codenvy/che-launcher:nightly start

Output shows ECLIPSE CHE: http://localhost:8080. It should show ECLIPSE CHE: http://192.168.56.110. I think that the fix is if a user provides -CHE_HOST_IP parameter, then we should return that value instead of localhost.

Offending code:
https://github.com/eclipse/che/blob/master/dockerfiles/che-launcher/launcher_funcs.sh#L120-L128

[TylerJewell]

@l0rd - FYI.

[l0rd]

tl;dr You should use CHE_HOSTNAMEto set Che server hostname and once #1644 is fixed you won't need CHE_HOST_IP anymore:

• The user env variable used to set the hostname is CHE_HOSTNAME.
• CHE_HOST_IP is the IP address used by the Che server to contact the wsagent (localhostin a Linux VM should work fine). That address don't correspond to the URL users have to put in their address bar (e.g. with Docker for Mac). But CHE_HOST_IP is used by the websocket running in the browser too: but in my opinion that's an issue and I've described it in Docker Launcher: Websockets are unable to comunicate with the wsagent when the server and the browser run on different networks #1644. Moreover CHE_HOST_IPis confusing and once Docker Launcher: Websockets are unable to comunicate with the wsagent when the server and the browser run on different networks #1644 is addressed user won't need to set it anymore (websockets will infer the URL based on the browser address bar).

[TylerJewell]

@l0rd - I find it confusing to tell users that they have to set CHE_HOSTNAME just to get proper output when the launcher starts up. I agree that #1644 is probably the best fix. Is #1644 assigned to anyone - ie, is anyone working on it for a proper resolution?

FYI, CHE_HOST_IP is essential here, otherwise the browser clients cannot communicate to the Che server running in the VM. So, it would be nice to have #1644 solved once and for all.

[l0rd]

That's the issue I'm currently working on :-) I can't assign it to myself otherwise I would have done so. Setting CHE_HOST_IP is a workaround until we don't fix #1644 and essential in some particular scenarios.

To infer CHE_HOSTNAME we should be able to guess if the launcher is running inside a VM. Or, when running on Linux OS we could default to the IP of the first network interface (e.g. eth0).

[JamesDrummond]

Can we remove the milestone and add sprint/next-sprint?

[l0rd]

@JamesDrummond Yes this issue should be removed from 4.6.0 milestone as well as #1644

[JamesDrummond]

@riuvshin Can you do this? I don't have access to do this yet for eclipse/che project.

[JamesDrummond]

@benoitf Thanks :) Can you do this for issue #1644 too when you get a chance. I will leave adding next-sprint up to you.

[JamesDrummond]

@benoitf Can you provide a status label for this?

[l0rd]

@TylerJewell Do you think that showing 2 URL would solve that issue?

Che external URL correspond to CHE_HOSTNAME (default to localhost on all platforms except boot2docker).
Che internal URL correspond to the IP of the Docker host (retrieved by get_docker_host_ip()).

[TylerJewell]

@l0rd - as an end user, I would probably find that confusing. It would be unclear to me which URL I should try, and it would not be intuitive for me to try an internal URL, because I would expect it to be internal-only.

[TylerJewell]

Pull request:
#2057

If you want to test this - you have to rebuild the codenvy/che-launcher:nightly image until our CI systems push it out.