Open Aransh opened 1 month ago
and has setOwnerReference enabled, it will create an invalid ownerReference, causing Kubernetes' garbage collector to immediately remove the resource, causing the workflow to fail with no explanation.
I'm surprised that k8s itself doesn't fail validation on this resource. The Controller does not currently validate the resource at all (it doesn't necessarily have schemas of all possible resources to do so) and leaves that to k8s. While this specific case of namespacing could be handled within Argo, the general case of k8s not validating sounds like an upstream issue
Pre-requisites
:latest
image tag (i.e.quay.io/argoproj/workflow-controller:latest
) and can confirm the issue still exists on:latest
. If not, I have explained why, in detail, in my description below.What happened? What did you expect to happen?
When deploying a resource as part of a workflow with setOwnerReference enabled, Argo Workflows does not validated the generated ownerReference. As I had to learn the hard way, in Kubernetes, "Cross-namespace owner references are disallowed by design" (See https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/). So If a Workflow creates a resource in another namespace, and has setOwnerReference enabled, it will create an invalid ownerReference, causing Kubernetes' garbage collector to immediately remove the resource, causing the workflow to fail with no explanation.
Optimally, I would expect Argo Workflows to know that and print logs about it as part of the step.
Version(s)
v3.5.8
Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflows that uses private images.
Logs from the workflow controller
Logs from in your workflow's wait container