[TEP-0098] Workflows - Problem Statement

[dibyom]

Adds a problem statement for the experimental workflows API. The goal is to start a discussion around the use cases we should target for Workflows. The approach I'm planning to take is to design and work on this in an experimental project once we have the use cases.
Moving from an experimental API to a full Tekton API is out of scope for now and can be considered depending on how the experimental project goes.

/cc @sbwsg @chmouel @khrm

[ghost]

/assign

[pritidesai]

/kind tep

[ghost]

Is deployment of all the necessary Tekton components a goal or non-goal? Thinking of a situation where a user starts with an empty cluster and needs (Pipelines, Triggers, Workflows, Remote Resolution) all deployed at versions that work together under the Workflows API. Is this something the Workflows project might provide or would we lean on the Operator project here instead maybe? Either way it might be worth calling out as in or out of scope here.

[dibyom]

Good point. Yeah I think I think we'd mention other projects as pre-requisites and installing them would be the user's job. They can use the operator project to simplify the installs.

[ghost]

/approve

[abayer]

So would this be a glue layer above both Pipelines and Triggers? I mean, in part, 'cos it does seem to be more than just that. =)

[khrm]

At present, the operator (for Openshift distribution) also provides a service account creation in every namespace with appropriate roles for triggers and pipelines. Will workflows deal with cluster-wide or namespaced scope changes? If latter, then there's no potential conflict in Operator and Workflow. If former, we will need to delegate some operator responsibilities to the latter or vice-versa.

[dibyom]

So, there is an SA per namespace and this SA is supposed to be used by the user in their pipelineruns/triggers etc?

Workflows will still allow users to set the SA to be used for the run, so if I'm understanding your question correctly, I think the operator SA will still work.

[dibyom]

Discussed this in the WG today - Operator installs a SA that contains the right roles/bindings/secrets needed to run triggers/pipelines. We can default to this SA optionally, but users can override the SA in the workflow spec.

[vdemeester]

Discussed this in the WG today - Operator installs a SA that contains the right roles/bindings/secrets needed to run triggers/pipelines. We can default to this SA optionally, but users can override the SA in the workflow spec.

Note: The SA setup in the operator is just a "different" SA than the default one to be able to run by default some of our shipped Tasks in OpenShift Pipelines. It is not required to run all Pipeline/Task, we are just setting it and using it as default SA instead of the default SA provided by k8s.

[dibyom]

Got it. It still sounds like this SA can be set as the default (perhaps by a mutating webhook) while the users can override it in their spec if they want.

[vdemeester]

Got it. It still sounds like this SA can be set as the default (perhaps by a mutating webhook) while the users can override it in their spec if they want.

We are using the config-defaults configmap provided by the tekton components for the most cases 😉

[dibyom]

So would this be a glue layer above both Pipelines and Triggers? I mean, in part, 'cos it does seem to be more than just that. =)

To start with, yes. Besides Pipelines and Triggers, we are also exploring adding other bits that are useful for CI workloads e.g. a concept of git repos, notifications etc.

[jerop]

API WG: will be discussed in Workflows WG

[chmouel]

Thanks for starting this,

One other things we may want to specify is if Workflow have only one pipeline definition attached with configuration assets or if we can have multiple pipelines.

If we can have multiple pipelines, I wonder if the Workfows can be a solution for Pipeline in Pipeline https://github.com/tektoncd/experimental/blob/main/pipelines-in-pipelines/README.md, where Workflow can compose multiple Pipeline together.

[vdemeester]

@chmouel do you mean multiple pipeline that run at the same time or multiple pipeline that run in different conditions (branches, tags, pull_request, …) or both ?

[dibyom]

We discussed this a bit at the WG last week - Notes

I think the use case was more like a pipeline in pipeline use case e.g a common security pipeline that is added to any user defined pipeline etc.

[vdemeester]

Discussed this in the WG today - Operator installs a SA that contains the right roles/bindings/secrets needed to run triggers/pipelines. We can default to this SA optionally, but users can override the SA in the workflow spec.

Note: The SA setup in the operator is just a "different" SA than the default one to be able to run by default some of our shipped Tasks in OpenShift Pipelines. It is not required to run all Pipeline/Task, we are just setting it and using it as default SA instead of the default SA provided by k8s.

[vdemeester]

@chmouel do you mean multiple pipeline that run at the same time or multiple pipeline that run in different conditions (branches, tags, pull_request, …) or both ?

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: khrm, sbwsg, vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• teps/OWNERS [khrm,vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jerop]

/lgtm

approved at API WG

(@dibyom to respond to nonblocking comments)

[chmouel]

/lgtm

🍺

[jerop]

/lgtm

it was already approved in API WG last week but needed rebasing before merging - rebasing removed the lgtm label so reapplying it