Jay Ganbat12/13/2022, 5:37 PM
Dan Rammer (hamersaw)12/13/2022, 5:40 PM
) that are stored in the admin DB. The precision of these is not always 100% reliable, as the timestamp often coincides with the Flyte event rather than the k8s operation. So task
will be when Flyte creates the Pod,
will be when the Pod enters the
is the last update. So if the pod succeeds, this is the final timestamp.
timestamp is when the Pod transitions to
but this still requires container image pull times, etc. It would be VERY usefully to have start / end times for single container runtimes. Then users know exactly how long their tasks ran, how much overhead attributes to k8s ops, and how much overhead attributes to flyte ops.
Jay Ganbat12/13/2022, 5:45 PM
Dan Rammer (hamersaw)12/13/2022, 5:48 PM
on a task should be when Flyte creates the k8s Pod and when the Pod transitions to
. IIUC this is the best we can currently do to capture the queued time you're looking for.
Jay Ganbat12/13/2022, 6:02 PM