-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
{{pod.name}}
value different when using retryStrategy
within templateDefaults
#13691
Comments
cannot reproduce in minikube/kind |
Thanks @chengjoey for looking at it. Do you mean that you can't reproduce the initial behaviour we had:
And what you've got is:
I would like to make sure what we currently have is an expected behaviour. |
I confirm that I CAN NOT reproduce this bug using |
{{pod.name}}
inconsistency{{pod.name}}
value different when using retryStrategy
withing templateDefaults
The issue happens when a |
{{pod.name}}
value different when using retryStrategy
withing templateDefaults
{{pod.name}}
value different when using retryStrategy
within templateDefaults
argo-workflows/workflow/controller/operator.go Lines 1946 to 1950 in bb9e555
argo-workflows/workflow/controller/operator.go Lines 1960 to 1964 in bb9e555
We should merge template defaults to template before we check if |
Signed-off-by: oninowang <[email protected]>
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: