I would like the user app to be recompiled with go 1.7.5 if that is not already the case

[rberlind]

I believe that the user app in version 0.4.4 might have been compiled with go 1.7.0. This has caused problems ("no reachable servers" errors) when running that version on Apcera in which I am using fully qualified DNS names of the form \<service>.apcera.local. I believe the problem will go away if the 0.4.4 version is recompiled using go 1.7.5. My reason for thinking this is that I found an issue which indicates that .onion and .local DNS names were not resolved in go 1.7, but that this was changed for *.local DNS names starting in go 1.7.1.

Additionally, I can use user 0.4.4 on Apcera if I use an Apcera job link to connect user to user-db; in this case, an IP and port are used instead of user-db.apcera.local. That confirms that the problem is having a DNS address ending in "local".

But to make absolutely sure, I compiled the user 0.4.4 source code with both go 1.7.0 and 1.7.5. Using 1.7.0 gave the no reachable server errors, while using 1.7.5 did not.

In theory, since the Dockerfile you are using is derived from the Docker image golang:1.7-alpine and this has been using go 1.7.5 since 2 months ago, the app should have already been compiled with go 1.7.5. But I would appreciate it if you can double-check and recompile with 1.7.5 if that is not already the case.

Thanks, Roger Berlind

[pidster]

If you submit a PR that updates the build Docker file to 1.7.5 we will rebuild & release it.

[rberlind]

Thanks pidster. Could you be more specific about exactly which Docker file needs to be updated? There are two at the project root (Dockerfile and Dockerfile-test) and one called Dockerfile-release under user/docker/user. I think you mean the Dockerfile under the project root, /user.

But the strange thing is that this one is already based off of golang:1.7-alpine which according to https://github.com/docker-library/golang/commits/349270dbc128e396888cb2423ffc85d2c3039a27/1.7/alpine/Dockerfile was upgraded from Go 1.7.0 to 1.7.1 on September 7, 2016, to 1.7.3 on October 19, 2016, to 1.7.4 on December 1, 2016, and to 1.7.5 on January 26, 2017. So, when Phil Winder upgraded the Docker file 2 weeks ago from golang:1.6-alpine to golang:1.7-alpine, Go 1.7.5 should have already been used if that is the actual Docker image on which the code was compiled. So, I don't think there is anything for me to change in that file.

I wonder if the problem is actually with the .travis.yml file which simply specifies "go: 1.7". Maybe that one needs to be updated to say "go: 1.7.5"? I admit to knowing very little about Travis.

I'll submit a pull request with that change. Perhaps you and Phil could discuss. If you think updating the Travis file is wrong, then please suggest a more specific change in one of the Docker files.

[rberlind]

I did do the pull request and ran the Travis build process a few times, eventually getting to the point where it wants the $(DOCKER_PASS) variable when logging into docker. Of course, I don't have that set in my version of the files.

[jasonrichardsmith]

resolved in #47

[rberlind]

Thanks Richard. I tested the new tag, master-5e88df65, on Apcera, and it can now connect to the user-db database since it is using Go 1.7.5.

I did have an issue with the user-db using that tag, but that is because of an issue I already know about with the base mongo docker image which recently had some modifications made to its docker-entrypoint.sh script which cause issues on Apcera. (Problems started with https://github.com/docker-library/mongo/commit/5fa47142887600edcd437e7689f40342b3572e71) I'm working around that issue for orders-db, carts-db, and now also users-db (with the new tag) by changing the start commands to start with mongod and not run the docker-entrypoint.sh script.

Thanks again for rebuilding with go 1.7.5. Setting that in the Travis file was the key.

Roger