@ancient-wolf-19325 what’s the proper way to register a workflow on flyte core so that it’s visible from the UI? right now I’m launching from my python virtual environment and all outputs are tracked in that shell rather than the online dashboard

To register a workflow on Flyte Core so it appears in the UI, use the pyflyte CLI with the register command. For example, run:

pyflyte register --project <project> --domain <domain> <path-to-source-directory>

This registers your workflow and tasks to the Flyte backend, making them visible and launchable from the Flyte UI. Running workflows directly in your Python environment (without registration) will not make them visible in the UI or tracked by the Flyte backend. For more details, see the Flyte registration guide and core concepts. Would you like a step-by-step example or more details on project/domain setup? Sources: - Running your workflow remotely - Core concepts: registering tasks and workflows 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 I’m running a pythonic remote registry, is this the wrong way to go about it?

Registering workflows using the Pythonic FlyteRemote API is a valid approach and supported by Flyte. You can use methods like

FlyteRemote.register_workflow

,

register_task

, or

register_script

to programmatically register entities to the Flyte backend, making them visible in the UI—provided you use the correct project, domain, and version settings. See FlyteRemote documentation and FlyteRemote API reference. However, if you encounter "module not found" or missing code issues, ensure you use fast registration (e.g.,

register_script

with proper

source_root

and

module_name

), as standard registration may not upload all code dependencies. See Flyte issue #4936 for common pitfalls. Would you like a step-by-step example of remote registration or troubleshooting tips? Sources: - Core concepts: registering in Python with FlyteRemote - FlyteRemote API reference - Flyte issue #4936: remote registration pitfalls 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 it seems that the reason we’re unable to see the projects is because the flyte UI is currently being port-forwarded to 8080 as well as flyte admin. The local host attempts to make a request to the /me route to identify who’s accessing the UI. I’d like to disable this check of somehow provide permissions? Can you help me understand how to fix this? Here’s the error in console

main-bf736f34.js:2 
 GET <http://localhost/me> net::ERR_CONNECTION_REFUSED

lockdown-install.js:1 SES_UNCAUGHT_EXCEPTION: null
lockdown-install.js:1 SES_UNCAUGHT_EXCEPTION: null
lockdown-install.js:1 SES_UNCAUGHT_EXCEPTION: null

select-project:1 Uncaught (in promise) Error: Access to storage is not allowed from this context.Understand this error
initial.CiTUZlrd.js:988 Uncaught (in promise) Error: Access to storage is not allowed from this context.

main-bf736f34.js:2 Error: invalid wire type 4 at offset 1
    at s.skipType (main-bf736f34.js:2:985345)
    at e.decode (main-bf736f34.js:2:446575)
    at r (main-bf736f34.js:2:1054758)
    at h (main-bf736f34.js:2:1093930)
    at async Object.queryFn (main-bf736f34.js:2:1107884)
(anonymous) @ main-bf736f34.js:2
Promise.catch
t.fetch @ main-bf736f34.js:2
n.executeFetch @ main-bf736f34.js:2
n.onSubscribe @ main-bf736f34.js:2
t.subscribe @ main-bf736f34.js:2
(anonymous) @ main-bf736f34.js:2
au @ vendor_react-bf736f34.js:2
xs @ vendor_react-bf736f34.js:2
ss @ vendor_react-bf736f34.js:2
$a @ vendor_react-bf736f34.js:2
(anonymous) @ vendor_react-bf736f34.js:2
Ss @ vendor_react-bf736f34.js:2
os @ vendor_react-bf736f34.js:2
O @ main-bf736f34.js:2
I @ main-bf736f34.js:2Understand this error
3main-bf736f34.js:2 Error: invalid wire type 4 at offset 1
    at s.skipType (main-bf736f34.js:2:985345)
    at e.decode (main-bf736f34.js:2:446575)
    at r (main-bf736f34.js:2:1054758)
    at h (main-bf736f34.js:2:1093930)
    at async Object.queryFn (main-bf736f34.js:2:1107884)

This issue is likely due to FlyteConsole and FlyteAdmin being port-forwarded on different ports, causing the UI to fail requests to

/me

and other API routes. By default, FlyteConsole expects FlyteAdmin to be accessible at the same origin, but with port-forwarding, this is not the case. You need to set the

ADMIN_API_URL

environment variable in the FlyteConsole config to explicitly point to the FlyteAdmin port (e.g.,

http://localhost:8089

), and ensure CORS is enabled in FlyteAdmin for the console's origin. See GitHub issue #416 and related discussion. To fix: 1. Update FlyteConsole's config to set

ADMIN_API_URL: http://localhost:<flyteadmin-port>

. 2. In FlyteAdmin config, set

allowCors: true

and add

allowedOrigins: ["http://localhost:<console-port>"]

. 3. Restart both pods after config changes. Would you like step-by-step YAML examples for these changes? Sources: - GitHub issue #416: Port-forwarding and ADMIN_API_URL - GitHub issue #6037: Projects not visible in UI 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 this is currently my port_forwarded_config.yaml

admin:
  endpoint: localhost:8089
  insecure: true

What else should I add to this? or do I need to set the configuration somewhere else?

Your

port_forwarded_config.yaml

is correct for CLI tools, but to fix the UI issue, you also need to update the FlyteConsole deployment to set the

ADMIN_API_URL

environment variable to

http://localhost:8089

. This tells the UI where to find FlyteAdmin. Additionally, ensure FlyteAdmin's config allows CORS from the console's origin. CLI config alone does not affect the UI—these changes must be made in the Kubernetes deployment configs for FlyteConsole and FlyteAdmin. See GitHub issue #416 and Union.ai security overview. Would you like the exact

kubectl

commands or YAML snippets to update these settings? Sources: - GitHub issue #416: Port-forwarding and ADMIN_API_URL - Union.ai security overview 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 yes please give me the exact kubectl commands

To update FlyteConsole and FlyteAdmin for port-forwarding, follow these steps: 1. Set ADMIN_API_URL in FlyteConsole:

kubectl edit deployment flyteconsole -n <flyteconsole-namespace>

Add or update the environment variable:

- name: ADMIN_API_URL
  value: http://localhost:8089

Then rollout the deployment:

kubectl rollout restart deployment/flyteconsole -n <flyteconsole-namespace>

2. Enable CORS in FlyteAdmin:

kubectl edit configmap flyte-admin-config -n <flyteadmin-namespace>

Add or update:

security:
  allowCors: true
  allowedOrigins:
    - 'http://localhost:8080'

Then rollout the deployment:

kubectl rollout restart deployment/flyteadmin -n <flyteadmin-namespace>

Replace

<flyteconsole-namespace>

and

<flyteadmin-namespace>

with your actual namespaces. For more, see Union.ai security overview and CORS config example. Sources: - Union.ai security overview - CORS config example 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.