Hi, does anyone have an idea how one could introspect the local filesystem of a container after the pod is completed? We ues FlyteFiles and FlyteDirectories a lot and currently have no possibility of browsing the created files after a pod has completed/errored without uploading the files to S3. For pods that terminate with error state, I assume, we could hack something using sidecar containers that dump a snapshot of the local filesystem to a PVC, but UserErrors are catched and handled gracefully with the pod finalizing in a Completed state (correct me if I am wrong) - in this situation it might be more difficult for the sidecar to distinguish between a successful completion and a user error and we would not want to take a snapshot of every single task, but only the failed ones. Does anyone have a better idea or is there even a flyte feature that could help already?

@Klemens Kasseroller hold your guns for the upcoming vscode integration that allows you to fly into the container at runtime. LinkedIn and union are working on it. At the moment this can be done as long as the container / Pod is around

Hi Ketan, the VSCode plugin sounds like an interesting feature, looking forward to it! Though, I think it addresses a slightly different problem - we sometimes have very long running productive workloads, which produce a lot of files. If such a task fails at upload or just after a long period of time, we are only able to reproduce the problem by rerunning the task and waiting for hours or hypothetically even days, to arrive at the exact same state, while, in fact, we could debug the task by simply looking at the created files. Kubernetes directly does not provide a way to run a shell in a completed pod, but maybe someone was already in a similar situation? A low-level solution would absolutely be enough for the time being.

This is what we intend to do with vscode plugin. It will drop you into an editor on failure