Argo: Workflows should be able to reference WorkflowTemplates entirely without templates

Created on 1 Apr 2020  路  11Comments  路  Source: argoproj/argo

Summary

Workflow-template need to be submitted periodically through Cron-Workflow

Motivation

In v2.7, templateRef has been removed from the template and the submittable workflowtemplate feature has been added. It would be a good feature to support the cron workflow to submit the workflow template periodically. This feature will enable the use-case to change the workflow definition without changing/resubmitting cronworkflow.

Please give examples of your use case, e.g. when would you use this.

Proposal

kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  timezone: "America/Los_Angeles"  
  startingDeadlineSeconds: 0
  concurrencyPolicy: "Replace"      # Default to "Allow"
  successfulJobsHistoryLimit: 4     # Default 3
  failedJobsHistoryLimit: 4         # Default 1
  suspend: false                    # Set to "true" to suspend scheduling
  workflowTemplateRef:
    name: workflow-template-submittable

How do you think this should be implemented?



Message from the maintainers:

If you wish to see this enhancement implemented please add a 馃憤 reaction to this issue! We often sort issues this way to know what to prioritize.

enhancement

Most helpful comment

I think this would be good if it were implemented at the Workflow level (instead of the CronWorkflow).

Currently the only way to submit a WorkflowTemplate is through the CLI, which converts it directly to a Workflow. If a WorkflowTemplate is actually a _definition_ of a Workflow, it should be possible for it to be instanciated on a Workflow object.

Perhaps by

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: test
spec:
  workflowTemplateRef:
    name: workflow-template-name
  arguments:
    parameters:
      - name: message
        value: "Hello, world"

That would allow a CronWorkflow to instantiate a WorkflowTempalte like so:

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  workflowSpec:
    workflowTemplateRef:
      name: workflow-template-name
    arguments:
      parameters:
        - name: message
          value: "Hello, world"

I fear that implementing the original suggestion would tangle all CronWorkflows, WorkflowTemplates, and Workflows together. I think the Workflow should be the only resource able to reference other resources (with the exception of WorkflowTemplates referencing themselves).

I would need to be able to pass arguments to the top-level ref, though.

Agree, we need to make sure this is supported as well.

I actually have some reservations about this, and about WorkflowTemplates having Arguments in general. I am hoping to discuss this internally today and create an issue after gathering feedback.

All 11 comments

While template.tempalteRef was deprecated, template.steps.templateRef and template.dag.task.templateRef weren't. Calling a WorkflowTemplate from a Workflow is still very much possible, it just needs to be done inside steps or dag.

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  workflowSpec:
    entrypoint: whalesay
    templates:
      - name: whalesay
        steps:
          - - name: call-whalesay-template
              templateRef:
                name: workflow-template-whalesay-template
                template: whalesay-template
              arguments:    # Inputs should be converted to arguments
                parameters:
                - name: message
                  value: Hello, world

I think it is a workaround. let's discuss and get feedback from users and team

FWIW, as somebody who just converted a bunch of existing CronWorkflows from using template.templateRef to using template.steps.templateRef, I'd 100% re-convert them back to using a dedicated top-level workflowTemplateRef field if that became an option. The extra syntactic noise of the steps is annoying, and it makes it tempting to add more logic there (vs. a top-level ref, which I feel pretty clearly indicates that all "real" logic should be in the template). I would need to be able to pass arguments to the top-level ref, though.

Alt: If WorkflowTemplate was extended to also support specifying all of CronWorkflow's scheduling parameters, that would be even better / cleaner IMO.

The extra syntactic noise of the steps is annoying, and it makes it tempting to add more logic there (vs. a top-level ref, which I feel pretty clearly indicates that all "real" logic should be in the template).

This is exactly my sentiment as well.

spec:
  workflowTemplateRef:
    name: workflow-template-submittable

Can we make sure that it is possible for Argo Events to also follow the proposed syntax?

I would need to be able to pass arguments to the top-level ref, though.

Agree, we need to make sure this is supported as well.

Thanks @jessesuen I will create an Issue in Argo Event and contribute it.

I think this would be good if it were implemented at the Workflow level (instead of the CronWorkflow).

Currently the only way to submit a WorkflowTemplate is through the CLI, which converts it directly to a Workflow. If a WorkflowTemplate is actually a _definition_ of a Workflow, it should be possible for it to be instanciated on a Workflow object.

Perhaps by

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: test
spec:
  workflowTemplateRef:
    name: workflow-template-name
  arguments:
    parameters:
      - name: message
        value: "Hello, world"

That would allow a CronWorkflow to instantiate a WorkflowTempalte like so:

apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  workflowSpec:
    workflowTemplateRef:
      name: workflow-template-name
    arguments:
      parameters:
        - name: message
          value: "Hello, world"

I fear that implementing the original suggestion would tangle all CronWorkflows, WorkflowTemplates, and Workflows together. I think the Workflow should be the only resource able to reference other resources (with the exception of WorkflowTemplates referencing themselves).

I would need to be able to pass arguments to the top-level ref, though.

Agree, we need to make sure this is supported as well.

I actually have some reservations about this, and about WorkflowTemplates having Arguments in general. I am hoping to discuss this internally today and create an issue after gathering feedback.

Implementing at the Workflow level makes sense to me as a user :+1:

I actually have some reservations about this, and about WorkflowTemplates having Arguments in general. I am hoping to discuss this internally today and create an issue after gathering feedback.

Having the ability to pass inputs to the entrypoint of the template is critical to my use-case, but I think we might be talking about two separate things. I'll comment on the other issue to clarify.

Having the ability to pass inputs to the entrypoint of the template is critical to my use-case, but I think we might be talking about two separate things. I'll comment on the other issue to clarify.

Correct, two different things 馃檪

To be super clear, I meant that WorkflowTemplates shouldn't be able to define Arguments in its own definition. Arguments should be passed into a WorkflowTemplate from its caller. #2559 is opened to address this.

For the submittable WorkflowTemplates PR, I think we should use the existing templateRef field. Something like

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: test
spec:
  templateRef:
    name: workflow-template-name
  arguments:
    parameters:
      - name: message
        value: "Hello, world"

templateRef without templateRef.tempalte set can indicate a WorkflowTemplate as a whole. This could be used to submit full WorkflowTemplates for anywhere else in the Workflow (such as steps or dag)

Just want to chime in as a user to say that I agree with the discussion so far and like the proposal!

Any updates on the status? Judging from some recent activity it seems that this has already been merged, but I can't find the specific PR (if it exists).

Was this page helpful?
0 / 5 - 0 ratings