opening a Che 7 workspace from factory fails due to cors

[gorkem]

Try creating a workspace with https://che.openshift.io/f?id=factorykfs97j9yp4c9wzwi
Although workspace is created successfully an error on the browser console can be seen and
the workspace is never opened

Failed to load resource: the server responded with a status of 503 (Service Unavailable)
loader.html:1 Access to XMLHttpRequest at 'https://routegvg4iz81-XXXXXXXX-che.8a09.starter-us-east-2.openshiftapps.com/jwt/auth' from origin 'https://che.openshift.io' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[PavelSosin]

I just made next step toward installation of Che 7 beta on top of my local kubernetes cluster. I created secret from company certificate pre-installed on my laptop by IT team when it was delivered to me. The next step, I suppose, will be ingress creation. Which type of ingress is suitable for Che7 in the personal evironment, see ((https://github.com/nginxinc/kubernetes-ingress/blob/master/docs/nginx-ingress-controllers.md))

[ibuziuk]

@gorkem i believe it is related to long route exposure - openshiftio/openshift.io#4695

[skabashnyuk]

@gorkem I was able to reproduce it in some cases

Agree with @ibuziuk more likely this is routes issue.
Because one request to jwt proxy finished with successful redirection but next request returned 500 http error.

@PavelSosin are you statement is related to this issue?

[ibuziuk]

@skabashnyuk do you think there could be some workaround for this?
page refresh does not seem to help

[ibuziuk]

funny thing that when I directly navigate to jwt-proxy route it keeps returning 503 even in a couple of minutes after workspace startup

[skabashnyuk]

@skabashnyuk do you think there could be some workaround for this?

I don't think so.

[ibuziuk]

I mean, is it expected that when all routes are exposed and accessible, page refresh would proceed with the redirect correctly?

[skabashnyuk]

The issue is that the route becomes available and then gone. I think we can't guarantee in this case anything.

[ibuziuk]

do you mean route flapping? AFAIK, on starter clusters there is only a problem related to the long route exposure (not route flapping)

[skabashnyuk]

I reproduce it with route flapping.

1. A successful request to JWT proxy with a redirect as a result.
2. Next request JWT proxy - 503 service unavailable from OpenShift.

[nickboldt]

This sounds like a problem we should fix in Che 7.1, if it's not already fixed in 7.0. If you agree please set a milestone and remove the triage label.

[skabashnyuk]

Does anyone reproduce it since February?
@ibuziuk wdyt?

[ibuziuk]

AFAIK, this is route flapping (not CORS) related issue,which should be closed since it is infrastructure specic. Currently, there is no route flapping on OSO clusters used by che.openshift.io