@ancient-wolf-19325 the logs on my flyte jobs are currently not displaying and I believe it's because flyte is setting the logging context somewhere. Is there a parameter I can set when launching an execution to make sure the logs aren't swallowed by the flyte context?

You can control Flyte's logging behavior using parameters like

log_level

,

log_format

, and

reset_root_logger

when launching a run. Setting

reset_root_logger=True

ensures the root logger is preserved and not modified by Flyte, which can help prevent logs from being swallowed by Flyte's logging context. You can pass this parameter via

flyte.with_runcontext(reset_root_logger=True)

when launching your execution. For more details, see the parameter table in llms-full.txt. Would you like more detail or example code? Sources: - llms-full.txt 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

What if I'm launching via remote_client.execute(...) @ancient-wolf-19325

When using

remote.execute(...)

(with

FlyteRemote

), there is no documented parameter to directly control Flyte's logging context or set

reset_root_logger

. The available options for

remote.execute

focus on execution metadata, inputs, and resource settings, but do not expose logging context controls as per the running_tasks.md and running_workflows.md documentation. Would you like more detail on possible workarounds or logging configuration at the cluster or container level? Sources: - running_tasks.md - running_workflows.md 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

Yeah a workaround would be great @ancient-wolf-19325

It could be possible that a workaround is to configure logging at the task or container level, rather than relying on Flyte's execution parameters. For example, you might explicitly set up your logger in your task code to use the desired handlers and levels, ensuring it does not propagate to or get overridden by Flyte's logging context. Another approach might be to configure your log aggregator or Flyte's logging links to point directly to your container or pod logs, as described in configuring_logging_links_in_the_ui.md. Though I'm not entirely certain, you might also consider using environment variables or container entrypoint scripts to set up logging before Flyte initializes, which could help preserve your logging configuration. Would you like step-by-step guidance on any of these approaches? Sources: - configuring_logging_links_in_the_ui.md 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.