Hi, I followed the guide for setting up flyte on GKE. I tried port forwarding the console to my local machine for testing purposes, but that resulted in an error. The command I used is

kubectl -n flyte port-forward service/flyteconsole 8080:80

The only thing I didn't follow in the guide is having a domain name. We don't want to expose this externally. But I am surprised the port forwarding doesn't work. Is the domain name used beyond just the ingress point?

@delightful-computer-49028 do you mind opening up your devtools in the browser and sending us the logs? What is the app domain and your admin request url? Are they are different and you're getting Access-Control-Allow-Origin errors?

We are running into the same issue. We aren’t getting any CORS errors from what we can see. But it can look like it expects the console and admin to be in the same domain. Following the GCP guide, would this be the case? We are also running Flyte on an internal cluster.

@wooden-sandwich-59360 if the failing request is a GET request do you get a response if you navigate to it in the browser, or otherwise do Postman type requests succeed when they're not coming from the same domain? Another way to check would be getting this extension for Chrome and setting up custom CORS rules. We've usually seen these when Access-Control-Allow-Origin headers are not properly set up on the server servicing these requests, but something else might be up that requires further investigation. Please feel free to send a video meeting at your earliest convenience so i can have a look on your machine, if that's ok.

So I dont actually configure a domain during setup because i don't have a domain to bind to flyte right now. After port forwarding I go to localhost:<forwarded port>. I found a work around this by following this github issue using envoy. It would be good if this was made available as part of the helm chart.

Thank you, I'll forward the feedback to our team. Happy to hear you found a workaround!

@delightful-computer-49028 you are right, unfortunately grpc and http ports have to be different, flyteconsole, by default, assumes flyteadmin is served on the same “domain” as the current browser window (so if you have localhost:8080/console, it’ll try to send a request to admin on localhost:8080/api/v1/projects for example)… there are a couple of work arounds here: 1. Port forward separately: a. flyteconsole, flyteadmin http and flyteadmin grpc separately (:8080, :8081, :8082 for example) b. Set FLYTE_ADMIN_URL to http://localhost:8081 c. I think you need to configure CORS rules to allow cookies across. 2. Use an ingress controller a. e.g. envoy/contour can be the one port to portforward and then all services appear to be served from the same port 3. Use the simpler, single-binary deployment (docs to follow), this helm chart

flyte-binary

comes with a single deployment, a single configmap and a proxy service that allows you to port-forward a single port to get both grpc and http protocols

Thanks alot for looking into this. I got flyteadmin to respond in the console by port-forwarding everything and setting the allowedOrigin to http://localhost:8080 and setting ADMIN_API_URL to http://localhost:8081. allowedOrigin ‘*’ won’t work when request includes withCredential: true. We will eventually put admin and console in the same domain and imagine this issue will go away with time.

that’s correct! we are working on simplifying the deployment to be that single-binary helm chart in all the docs… which gives you the single port forwarding experience out of the box… thank you for bearing with us through that