New RunLLM response generated: >>>*# Question* Hi...
# runllm-flyte-trial
a
New RunLLM response generated: >>>*# Question* Hi all, I'm using Flyte in GCP with GCSFuse CSI driver. The driver mounts a sidecar container, which waits for all other containers to terminate before terminating itself. The problem is that Flyte Copilot also does the same - waits for all other containers to terminate, which causes a deadlock between the two where they wait on each other to terminate. I had a workaround for that where I explicitly sent a SIGTERM to the GCSFuse sidecar, which terminated it. (For some reason it worked only 90% of the time) But after upgrading my GKE cluster to 1.29, the GCSFuse sidecar is injected as an init-container with
restartPolicy: Always
, which means my workaround doesn't work anymore. Does anyone know how can I fix it easily? Our pipelines are now stuck because of this, as it is impossible to downgrade the GKE cluster Thanks! # Answer The issue you're facing is a known problem when using sidecars with Flyte, especially when both the Flyte Copilot and another sidecar (like GCSFuse) wait for each other to terminate, causing a deadlock. Here are a few potential solutions: 1. Disable Sidecar Injection: You can disable the sidecar injection for the Flyte tasks. This can be done by adding the annotation
sidecar.istio.io/inject: "false"
to the pod spec. This prevents the sidecar from being injected into the Flyte task pods. 2. Use Flyte Pod Task: Flyte's Pod task can be configured to only monitor the primary container, ignoring the sidecars. This can be done by setting the
primary_container_name
in the
Pod
task configuration. This way, Flyte will consider the task complete when the primary container finishes, regardless of the sidecar's state. 3. Configure Deletion Policy: You can configure Flyte to delete resources upon task completion by setting the
delete-resource-on-finalize
option. This ensures that the pods are cleaned up immediately after the task completes, which might help in avoiding the deadlock. Here is an example of how to configure a Flyte Pod task to only monitor the primary container:
Copy code
import typing
import pandas as pd
import numpy as np
from flytekitplugins.pod import Pod
from kubernetes.client.models import V1Container, V1PodSpec
from flytekit import task, workflow

def generate_pod_spec_for_task():
    primary_container = V1Container(name="primary")
    pod_spec = V1PodSpec(containers=[primary_container])
    return pod_spec

@task(task_config=Pod(pod_spec=generate_pod_spec_for_task(), primary_container_name="primary"))
def generate_normal_df(n: int, mean: float, sigma: float) -> pd.DataFrame:
    return pd.DataFrame({"numbers": np.random.normal(mean, sigma, size=n)})

@task(task_config=Pod(pod_spec=generate_pod_spec_for_task(), primary_container_name="primary"))
def compute_stats(df: pd.DataFrame) -> typing.Tuple[float, float]:
    return float(df["numbers"].mean()), float(df["numbers"].std())

@workflow
>>```
def wf(n: int = 200, mean: float = 0.0, sigma: float = 1.0) -> typing.Tuple[float, float]: return compute_stats(df=generate_normal_df(n=n, mean=mean, sigma=sigma))
Copy code
Additionally, you can configure the deletion policy in your Flyte deployment configuration:
configmap: schedulerConfig: gc-interval: 10m # can leave blank for 30m delete-resource-on-finalize: true ``` Would you like more details on any of these solutions? Sources: - Flyte Community Discussion on Sidecars - Flyte Community Discussion on Deletion Policy Slack Link https://flyte-org.slack.com/archives/CP2HDHKE1/p1721219187.763649 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.