workspace never comes up when Che deployed with single-host strategy

[tolusha]

Describe the bug

Che workspace never comes up when Che deployed with single-host strategy

Che version

• latest

Expected behavior

Runtime

• minikube (include output of minikube version and kubectl version)

Screenshots

Installation method

Actually chectl doesn't support changing server strategy. That's why I modified sources
https://github.com/che-incubator/chectl/blob/master/src/tasks/installers/helm.ts#L349 by adding setOptions.push('--set global.serverStrategy=single-host')

• chectl ./run server:start --platform=minikube --installer=operator --che-operator-cr-patch-yaml <patch_yaml>

spec:
  k8s:
    ingressStrategy: single-host

Environment

• my computer
  • Linux

jwt-proxy container log

time="2020-07-14T09:46:00Z" level=info msg="Starting reverse proxy (Listening on ':4402')" 
time="2020-07-14T09:46:00Z" level=info msg="Starting reverse proxy (Listening on ':4400')" 
time="2020-07-14T09:46:00Z" level=info msg="Starting reverse proxy (Listening on ':4401')" 
2020/07/14 09:48:30 [008] WARN: Error reading handhsake response  unexpected EOF
2020/07/14 09:48:30 [008] WARN: Websocket handshake error: unexpected EOF
2020/07/14 09:48:30 http: response.WriteHeader on hijacked connection from github.com/eclipse/che-jwtproxy/vendor/github.com/coreos/goproxy.(*ProxyHttpServer).ServeHTTP (proxy.go:149)
2020/07/14 09:48:30 http: response.Write on hijacked connection from io.copyBuffer (io.go:404)

Additional context

#14564

[tolusha]

I am wondering if we have correct ingress path - path: /serverguzkttwj/jwtproxy-server-4402/(.*) in workspace namespace.
Should it be like - path: /serverguzkttwj-jwtproxy-server-4402/(.*) ?

[l0rd]

@vzhukovskii It looks like you have done the triage but you have not set the issue severity and area labels.
@tolusha that's look quite critical hence setting P1, I remember testing it on minikube a few months ago and I could start workspaces. That happens for every workspace?

[tolusha]

@l0rd
right, for every workspace.
How did you deploy Eclipse Che if single-host was broken?

[l0rd]

@tolusha I had created 2 new ingresses for the registries (manually)

[sparkoo]

@tolusha @l0rd I'm meeting the same issue. Also I can see this in Theia log

2020-07-21 15:25:13.344 root ERROR Refused a WebSocket connection: 127.0.0.1

So it may be involved somehow in the issue.

[sparkoo]

I've tried to run with eclipse/che-theia/7.12.0 and it "somehow" works (understand somehow here that it's probably my fault it's not fully working for me as I have very crooked setup)
So my bet is it is Theia regression.

[benoitf]

There is a check in che-theia to refuse websockets connection from invalid source https://github.com/eclipse/che-theia/blob/master/extensions/eclipse-che-theia-messaging/src/node/messaging/che-messaging-contribution.ts#L46

[sparkoo]

There is a check in che-theia to refuse websockets connection from invalid source https://github.com/eclipse/che-theia/blob/master/extensions/eclipse-che-theia-messaging/src/node/messaging/che-messaging-contribution.ts#L46

looks like our winner

[sparkoo]

btw, this issue currently blocks new single-host efforts #12914.

[sparkoo]

I think I found and fixed the issue. https://github.com/eclipse/che-theia/blob/master/extensions/eclipse-che-theia-messaging/src/node/messaging/che-messaging-contribution.ts#L81

The objects here looks like this:

2020-07-22 12:40:22.990 root INFO theiaEndpoints: [{"codeUri":{"$mid":1,"path":"/server0lrge5i9-theia-idexh4/server-3130/","scheme":"https","authority":"che.192.168.39.154.nip.io"}},{"codeUri":{"$mid":1,"path":"/serverz6bqowu3-jwtproxy/server-4402/","scheme":"https","authority":"che.192.168.39.154.nip.io"}}] 
2020-07-22 12:40:22.990 root INFO requestOriginURI: {"codeUri":{"$mid":1,"path":"/","scheme":"https","authority":"che.192.168.39.154.nip.io"}}

isEqualOrParent function looks like this (https://github.com/eclipse-theia/theia/blob/14531578a1eac6af55c6177ea857d39c38c9f09b/packages/core/src/common/uri.ts#L202):

isEqualOrParent(uri: URI): boolean {
  return this.authority === uri.authority && this.scheme === uri.scheme && this.path.isEqualOrParent(uri.path);
}

issue is in this.path.isEqualOrParent(uri.path) where we are comparing them in reverse. Swapping them fixes the issue.

[sparkoo]

PR merged eclipse-che/che-theia#812, closing this issue.