{{pod.name}}
value different when using retryStrategy
within templateDefaults
#13691
Open
2 of 4 tasks
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 usingPOD_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.11This 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.The issue is reproduced using the minimal workflow below:
> argo logs test-pod-name-plf6v test-pod-name-plf6v-get-pod-name-1010547582 -n argo test-pod-name-plf6v-get-pod-name-1010547582: pod.name=test-pod-name-plf6v-get-pod-name-3577080563
The value returned by
{{pod.name}}
is not the one we expected. It seems to return thenode
or typeretry
ID. For example:pod.name=test-pod-name-8zrgl-get-pod-name-2484369038
- we were expecting to havetest-pod-name-8zrgl-get-pod-name-121682877
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: