@dylanspag-lmco thanks so much for your effort so far. I've been talking to other maintainers about this change and we think the best path forward is to no accept it as it would break RawContainer functionality, the only instance where the copilot container is used in Flyte.
Flyte needs a way to determine that the user code finished execution and to capture the outcome (Success/Failure) and three mechanisms were envisioned to achieve that goal as described in the original flytecopilot design

  1. Poll the kube-api: it would require less process on the user code but a deeper investigation/benchmarking to determine the sane defaults to configure the kube-client and avoid overloading the kube-api server. Recent testing showed that this won't work, and it would require to spend time updating the code.
  2. Implement a file-based protocol. With this option, the user code had to include logic to drop the outputs to a certain directory and make the User code use a FileWatcher to determine the result of its own execution. Depending on the outcome (SUCCESS/FAILURE) it would need to write a different file, all of that before returning. Recent testing shows that it works butthere are potential performance implications going this route.Also, there is now wat to inspect that user code ran, just waiting for a file to drop.

Notice that for the two options above there is no way to activate them or select them, no flag.

  1. Share process namespace between copilot and the user code container (current default). With this mechanism, the copilot container downloads the inputs, watches the user code container for a result (using the shared process namespace and, hence, requiring the SYS_PTRACE capability), and copies the outputs, or updates flyteadmin, depending on whether the task succeeded or failed, respectively.

Considering this context, we cannot make SYS_PTRACE configurable because then we'd also have to disable RawContainer, and also there is no flag today to do so.
The closest acceptable change would be about creating that flag and exposing it on the Helm chart.

I hope the above explanation help in some way, and please let us know how we can help you with your current use case.

Select a repo