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

Unquoted expressions in WorkflowTemplate resource manifest fail validation #10924

Closed
3 tasks done
crowcrow opened this issue Apr 16, 2023 · 0 comments · Fixed by #10926
Closed
3 tasks done

Unquoted expressions in WorkflowTemplate resource manifest fail validation #10924

crowcrow opened this issue Apr 16, 2023 · 0 comments · Fixed by #10926
Assignees
Labels
area/templates/resource area/templating Templating with `{{...}}` P1 High priority. All bugs with >=5 thumbs up that aren’t P0, plus: Any other bugs deemed high priority P3 Low priority type/bug

Comments

@crowcrow
Copy link
Contributor

Pre-requisites

  • I have double-checked my configuration
  • I can confirm the issues exists when I tested with :latest
  • I'd like to contribute the fix myself (see contributing guide)

What happened/what you expected to happen?

When submitting a workflow template that has a 'complex'=(not directly resolvable) unquoted expression (see attached workflow's containerPort in the resource manifest) we get a validation error which is a false positive. It occurs because the expression remains unresolved which breaks the yaml syntax during the unmarshalling.

It is a valid concern because as we know all input parameters are strings (or at least should be according to the schema), so there are cases when we must cast the string to a type which is expected by the applied resource's manifest (e.g: containerPort).
The current 'workaround' is to have the input parameter's value supplied as an int (unquoted):

        parameters:
          - name: intParam
            value: 20

So that in the resource manifest we can reference the input parameter directly and unquoted (i.e: containerPort: {{inputs.parameters.intParam}}), which works because it is not an expression and is replaced with a placeholder before yaml validation, but there are several issues with that:

The solution is quite simple - basically we should replace the unresolved expressions with placeholders as well, so that the yaml unmarshalling succeeds - just for validation (because the actual expression evaluation will happen later). Will have a PR submitted later today.

Version

latest

Paste a small 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: WorkflowTemplate
metadata:
  generateName: valid-resource-
spec:
  entrypoint: whalesay
  templates:
    - name: whalesay
      inputs:
        parameters:
          - name: intParam
            value: '20'
          - name: strParam
            value: 'foobarbaz'
      outputs: {}
      metadata: {}
      resource:
        action: create
        manifest: |
          apiVersion: v1
          kind: Pod
          metadata:
            generateName: {{workflow.name}}-
          spec:
            restartPolicy: Never
            containers:
            - name: 'foo'
              image: docker/whalesay
              command: [cowsay]
              args: ["{{=sprig.replace("bar", "baz", inputs.parameters.strParam)}}"]
              ports:
              - containerPort: {{=asInt(inputs.parameters.intParam)}}

Logs from the workflow controller

# workflow controller doesn't print any errors (just returns 500: {"code":2,"message":"templates.whalesay.resource.manifest must be a valid yaml"})

# logs from workflow-server
time="2023-04-16T09:19:43.867Z" level=error msg="finished unary call with code Unknown" error="templates.whalesay.resource.manifest must be a valid yaml" grpc.code=Unknown grpc.method=CreateWorkflowTemplate grpc.service=workflowtemplate.WorkflowTemplateService grpc.start_time="2023-04-16T09:19:43Z" grpc.time_ms=0.626 span.kind=server system=grpc

Logs from in your workflow's wait container

N/A
@crowcrow crowcrow changed the title Unquoted expressions in WorkflowTemplate resource manifest fails validation Unquoted expressions in WorkflowTemplate resource manifest fail validation Apr 16, 2023
crowcrow added a commit to crowcrow/argo-workflows that referenced this issue Apr 16, 2023
…ate. Fixes argoproj#10924

Signed-off-by: Alexander Crow <acrow@akamai.com>
crowcrow added a commit to crowcrow/argo-workflows that referenced this issue Apr 18, 2023
Signed-off-by: Alexander Crow <acrow@akamai.com>
@sarabala1979 sarabala1979 added P3 Low priority P1 High priority. All bugs with >=5 thumbs up that aren’t P0, plus: Any other bugs deemed high priority labels Apr 20, 2023
terrytangyuan pushed a commit that referenced this issue Apr 24, 2023
…ate. Fixes #10924 (#10926)

Signed-off-by: Alexander Crow <acrow@akamai.com>
terrytangyuan pushed a commit that referenced this issue May 25, 2023
…ate. Fixes #10924 (#10926)

Signed-off-by: Alexander Crow <acrow@akamai.com>
JPZ13 pushed a commit to pipekit/argo-workflows that referenced this issue Jul 4, 2023
dpadhiar pushed a commit to dpadhiar/argo-workflows that referenced this issue May 9, 2024
…ate. Fixes argoproj#10924 (argoproj#10926)

Signed-off-by: Alexander Crow <acrow@akamai.com>
Signed-off-by: Dillen Padhiar <dillen_padhiar@intuit.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/templates/resource area/templating Templating with `{{...}}` P1 High priority. All bugs with >=5 thumbs up that aren’t P0, plus: Any other bugs deemed high priority P3 Low priority type/bug
Projects
None yet
3 participants