{{pod.name}}
inconsistency
#13691
Labels
area/controller
Controller issues, panics
area/templating
Templating with `{{...}}`
P3
Low priority
type/bug
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?
Using Argo Workflows v3.5.5 on an AWS EKS cluster with version 1.28, we had a task that was using the
{{pod.name}}
to generate a path to our S3 artifact bucket. The value returned by{{pod.name}}
was composed by:[WORKFLOW NAME]-[TASK NAME]-[POD ID]
(the same value as the directory created under our s3 artifact bucket for the pod running our task).We did an upgrade of our cluster from EKS 1.28 to 1.29. Since this upgrade,
{{pod.name}}
is returning a string composed by:[WORKFLOW NAME]-[TASK NAME]-[TASK ID]
(TASK ID instead of POD ID). But the directory created under our S3 artifact bucket is still composed using the generated name[WORKFLOW NAME]-[TASK NAME]-[POD ID]
as prior our upgrade. Note that we did not upgrade Argo Workflows, and did not deleted the cluster prior to the upgrade.We first suspected that we might have been in a weird state where Argo Workflows was using
POD_NAMES=v1
due to a previous Argo Workflows version we had on the cluster, and by upgrading the cluster an Argo Workflow server / controller node might have been "restarted" using the new default valuePOD_NAMES=v2
. But our tests by usingPOD_NAMES=v1
show that the{{pod.name}}
is now returning a string composed by[TASK NAME]-[TASK ID]
.Now the weird thing is that we deployed a brand new cluster, using EKS 1.28 and Argo Workflows 3.5.5, and we also encounter the issue of having
{{pod.name}}
returning[WORKFLOW NAME]-[TASK NAME]-[TASK ID]
and the S3 artifact bucket folder being[WORKFLOW NAME]-[TASK NAME]-[POD ID]
.Same behaviour is also observed using EKS 1.30 and Argo Workflows 3.5.11
This issue would be hard to reproduce. I am linking our public repository that uses Argo Workflows with our IaC for our cluster: https://github.com/linz/topo-workflows/tree/master/infra and the task that is using
{{pod.name}}
is here.Thank you for your help.
Version(s)
v3.5.5
v3.5.11
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
The text was updated successfully, but these errors were encountered: