management console invalid kubernetes URL with external kubernetes

[phemmer]

When using an external kubernetes (openshift start --kubernetes=...), the management console instructs the browser to contact kubernetes with invalid URLs. See the errors in the below screenshot.

Started as:

docker run \
  -d \
  --privileged \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --net=host \
 openshift/origin \
  start master \
  --kubernetes=http://localhost:8080 \
  --etcd=localhost

So the javascript is telling the browser to use https, when kubernetes is running over http.
It also appears to be instructing the browser to use the hostname passed in --kubernetes when starting openshift. This may not be the appropriate address, as in this case, it's localhost, but from my browser's perspective, it shouldn't be localhost.

---

The solution to this might be the same as the solution to #813. If a kubernetes proxy is added, the browser can be instructed to contact openshift for everything. Since the openshift daemon handles both the management console, and the API, determining the address the browser needs to use becomes easy.

[smarterclayton]

@jwforres as we discussed today, I believe the solution is going to be the proxy. Agree?

[phemmer]

One thing I noticed when I was running the simple proxy I mentioned on #813 is that websockets don't appear to work right. After sitting on the page for a while (5-10 min, cant recall exact time), the browser starts trying to get a websocket connection over and over. I haven't tried the code in #839, but the core of it basically identical, so it might suffer the same issue.

[smarterclayton]

All connections are terminated after 5 min - it's possible this is the corrupted http connection in the pool issue (we've hit it elsewhere). If you get trace info let me know

On Feb 2, 2015, at 11:53 PM, Patrick Hemmer notifications@github.com wrote:

One thing I noticed when I was running the simple proxy I mentioned on #813 is that websockets don't appear to work right. After sitting on the page for a while (5-10 min, cant recall exact time), the browser starts trying to get a websocket connection over and over. I haven't tried the code in #839, but the core of it basically identical, so it might suffer the same issue.

—
Reply to this email directly or view it on GitHub.

[phemmer]

It looks like the reverse proxy is stripping the websocket headers (stuck a tcpdump between openshift & kubernetes), so kubernetes is receiving a plain http request, and is responding with 200.

[jwforres]

@phemmer you need to also specify --public-kubernetes during openshift start if you expect the mgmt console to communicate with the kubernetes API on a different host than you specified for --kubernetes

[phemmer]

@jwforres does that mean you're against a proxy?

[jwforres]

No, just saying there is already a parameter in place to let you specify what the public-kubernetes URL should be and the web console will honor whatever its set to. You may still need the proxy for auth reasons.

[smarterclayton]

I think with the proxy we won't need public-kubernetes anymore. However, we'll leave it in until someone comes up with a reason not to have it.

----- Original Message -----

No, just saying there is already a parameter in place to let you specify what
the public-kubernetes URL should be and the web console will honor whatever
its set to. You may still need the proxy for auth reasons.

---

Reply to this email directly or view it on GitHub:
#820 (comment)

[smarterclayton]

@phemmer so basically the proxy needs to do upgrades? @ncdc i knew we'd need it.

[ncdc]

@smarterclayton good thing I have that working in my PR 😃

[smarterclayton]

@ncdc breaking your upgrader out in a way we can consume it here would be good.

[ncdc]

@smarterclayton which is higher priority, kubernetes/kubernetes#3763 completed with test cases etc, or a separate upstream PR just for the proxy upgrades?