3.4Rc4 - ${metadata.name} seems to always get the workflow name, not pod name

[tim-sendible]

Checklist

• [x] Double-checked my configuration.
• [x] Tested using :latest images.

Summary

What happened/what you expected to happen? In accordance with the documentation, I should be able to place ${metadata.name} into a custom pod link and it should output the pod name. Instead, it always outputs the workflow name.

This is a regression from 3.3.

I have tried with POD_NAMES set to v1 and this seems to resolve the issue.

What version are you running? 3.4 rc4

---

Message from the maintainers:

Impacted by this regression? Give it a 👍. We prioritise the issues with the most 👍.

[terrytangyuan]

@JPZ13 Would you like to look into this when you get a chance?

[JPZ13]

@JPZ13 Would you like to look into this when you get a chance?

Happy to. I'm a little tied up for the rest of the day, but @rohankmr414, could you take a look at this today and post any of your findings? I'll then take it from there

Also, @terrytangyuan what do we want the ideal behavior to be? The documentation says ${metadata.name}: Name of the current workflow / pod / event source / sensor but now that the workflow name and the pod name have diverged with pod names v2, it might make more sense to have the ${metadata.name} variable be the workflow name and add another variable to get the pod name. More than happy to go with whichever cc @tim-sendible

[sarabala1979]

@terrytangyuan @JPZ13 is it blocker for 3.4 GA?

[JPZ13]

@sarabala1979 I personally think it makes more sense to have ${metadata.name} interpolate to the workflow name and wouldn't consider this a 3.4 GA release blocker, but I also want to hear @terrytangyuan and @tim-sendible's thoughts

[terrytangyuan]

Workflow name sounds more reasonable to me.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is a mentoring request, please provide an update here. Thank you for your contributions.

[tico24]

Still an issue.

[sarabala1979]

@tim-sendible can you try with latest version?https://github.com/argoproj/argo-workflows/pull/9740

[JPZ13]

I synced with @tim-sendible today - the ${metadata.name} field is working properly in the workflow-controller-configmap on the latest version

[JPZ13]

I would suggest closing this issue

[tim-sendible]

Agreed. From what I saw on @JPZ13's screen it all looks good now. Thanks.

[as42sl]

Still an issue with 3.4.1! This used to work in previous versions. Please allow to reference the pod name in links

[boniek83]

It almost works in 3.4.2: For this link: http://grafana.home.local/explore?orgId=1&left=%7B%22datasource%22:%22Loki%22,%22queries%22:%5B%7B%22expr%22:%22%7Bcontainer%3D%5C%22main%5C%22,pod%3D%5C%22${metadata.name}%5C%22%7D%22,%22refId%22:%22A%22,%22editorMode%22:%22code%22,%22queryType%22:%22range%22%7D%5D,%22range%22:%7B%22from%22:%22now-3h%22,%22to%22:%22now%22%7D%7D ${metadata.name} is correctly resolved to a pod BUT %3D is not resolved to a = so loki gets this query: {container%3D"main",pod%3D"backfill-worker-go62jrw-962151937"} instead of this: {container="main",pod="backfill-worker-go62jrw-962151937"} It all worked well in 3.3.x

[tico24]

@boniek83 - this is a different issue to the one I raised. I have covered it in #9935