@ancient-wolf-19325 for flytev2 is there a way to specify TTL once they have finished or failed so that they can be cleaned up ?

The Flyte's documentation I have ingested does not mention how to specify a TTL (time-to-live) for runs or tasks after they have finished or failed in Flyte v2, nor does it describe any built-in mechanism for automatic cleanup of completed or failed runs based on TTL. If you are looking for automated resource cleanup or retention policies, please specify whether you mean workflow executions, task pods, or data artifacts, as this context could help clarify your needs. If this doesn't help, please reach out to the Flyte support team for further assistance. 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

@ancient-wolf-19325 well specifically runs. Some runs failed because of small bugs and now I can see pods still alive on my cluster with albeit an Errored state

The Flyte documentation I have ingested does not mention how to configure a TTL (time-to-live) for runs such that pods associated with failed or completed runs are automatically cleaned up after a certain period; there is no reference to a built-in TTL controller or similar cleanup mechanism for lingering pods in an errored state. If you are specifically seeing pods remain after runs fail, it may help to clarify whether these are driver pods, worker pods, or sidecars, and whether your Flyte deployment is managed or self-hosted, as this can affect pod lifecycle management. If this doesn't help, please reach out to the Flyte support team for further assistance. 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

@ancient-wolf-19325 self hosted flytev2 oss. Worker pods

It seems likely that Flyte v2 OSS does not provide a direct configuration for TTL (time-to-live) on worker pods after runs finish or fail. The documentation does not mention a built-in TTL controller or automatic cleanup for worker pods in errored or completed states; pod lifecycle is managed by Kubernetes, and Flyte does not appear to inject TTL settings into pod specs by default. You may need to use Kubernetes-native solutions like the TTL controller for finished resources or manually clean up pods. If you want to customize pod behavior, Flyte supports pod templates for advanced use cases, but TTL is not explicitly documented as a supported field in Flyte's pod template integration. Would you like more detail on using Kubernetes TTL controllers or Flyte pod templates? Sources: - pod templates 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

@ancient-wolf-19325 is there a way to specify the setting on helm chart ? Also how would you use podTemplates ? Afaik TTL can be set on Jobs

My understanding is that the Flyte OSS Helm chart does not expose a direct setting for Kubernetes TTL on pods or jobs; the available pod template and deployment settings in the chart do not mention TTL fields for finished pods or jobs. Flyte tasks are typically run as pods, not as Kubernetes Jobs, so the native TTL controller for Jobs does not apply unless you are using a plugin that wraps tasks in Jobs. For pod customization, you can use Flyte's pod templates by defining a

PodTemplate

in Python and passing it via the

pod_template

parameter in your

TaskEnvironment

. However, the documentation does not show TTL fields as supported in these templates. Here is a basic usage example:

import flyte
from kubernetes.client import V1PodSpec, V1Container

pod_template = flyte.PodTemplate(
    primary_container_name="primary",
    pod_spec=V1PodSpec(
        containers=[V1Container(name="primary")]
    ),
)

env = flyte.TaskEnvironment(
    name="my_env",
    pod_template=pod_template,
)

Would you like more detail on Kubernetes-native TTL controllers or further pod template customization? Sources: - pod templates 👍 0 button 👎 0 button 💡 Hint: Mention @herald in the thread for followups.

@swift-church-94876 did you figure this out?

Yeah flyte has 1hr time limit set, the gc auto cleanups the pods