Skip to content
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

Templated mutex name not resolved #13629

Open
2 of 4 tasks
nicolasbillamboz-flowbird opened this issue Sep 19, 2024 · 4 comments · May be fixed by #13648
Open
2 of 4 tasks

Templated mutex name not resolved #13629

nicolasbillamboz-flowbird opened this issue Sep 19, 2024 · 4 comments · May be fixed by #13648
Labels
area/templating Templating with `{{...}}` type/bug

Comments

@nicolasbillamboz-flowbird
Copy link

nicolasbillamboz-flowbird commented Sep 19, 2024

Pre-requisites

  • I have double-checked my configuration
  • I have tested with the :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.
  • I have searched existing issues and could not find a match for this bug
  • I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?

The mutex name is not resolved correctly when it is based on a workflow parameter, which is also based on another workflow parameter.

See the workflow below.

  1. mutex name is defined as {{ workflow.parameters.derived-mutex-name }}
  2. derived-mutex-name is defined as "{{ workflow.parameters.base-mutex-name }}"
  3. base-mutex-name is defined as a parameter of the argo submit command line, let's say mycustommutex

In this workflow dag is used (and might be the reason of the defect).

With this workflow, if I run the following command:

argo submit my-workflow.yml --parameter base-mutex-name=mycustommutex

I get the following message indicating the name of the mutex at runtime:

Waiting for argo-wf/Mutex{{ workflow.parameters.base-mutex-name }} lock. Lock status: 0/1

However the command echo {{ workflow.parameters.derived-mutex-name }} outputs correctly the resolved name:

mycustommutex

I have not tested this scenario with the latest version, because I'm not responsible of the deployment of argo in my company.

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.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: mutex-name-
spec:
  entrypoint: main
  arguments:
    parameters:
    - name: base-mutex-name
    - name: derived-mutex-name
      value: "{{ workflow.parameters.base-mutex-name }}"
  templates:
  - name: main
    dag:
      tasks:
      - name: first
        template: print-mutex-name
      - name: second
        template: print-mutex-name
  - name: print-mutex-name
    synchronization:
      mutex:
        name: "{{ workflow.parameters.derived-mutex-name }}"
    container:
      image: alpine
      command: [ "/bin/sh", "-c" ]
      args:
      - |
        #!/bin/bash
        echo {{ workflow.parameters.derived-mutex-name }}
        sleep 30

Logs from the workflow controller

I'm not granted the permission to get these logs

Logs from in your workflow's wait container

I'm not granted the permission to get these logs
@agilgur5 agilgur5 added the area/templating Templating with `{{...}}` label Sep 19, 2024
@agilgur5 agilgur5 changed the title Mutex name badly resolved Templated mutex name not resolved Sep 19, 2024
@chengjoey
Copy link
Contributor

Can't reproduce with v3.5.8 and latest

@nicolasbillamboz-flowbird
Copy link
Author

Here's some screenshots:
image
image

@chengjoey
Copy link
Contributor

chengjoey commented Sep 23, 2024

i got what you mean, UI shows that mutex is not replaced correctly

mutex function is actually available, but it is not replaced in the UI.

@nicolasbillamboz-flowbird
Copy link
Author

Just to precise that when the mutex is named after a workflow parameter which is static, the UI shows the correct name. The issue is about the "double" resolution of the name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/templating Templating with `{{...}}` type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants