[TEP-0044]: Refocus on Execution Options

[lbernick]

This commit renames TEP-0044 to "More Execution Options for Pipelines" and re-focuses it on giving
users more control over how their Pipelines are executed. There are two reasons for this change:

• The problems identified with how Tasks are executed (pod overhead and difficulty passing data between Tasks)
  are relevant only when executing multiple Tasks together, not when a single Task is executed in a TaskRun.
• The title "Decoupling Scheduling from Execution" implies that we must choose a runtime-based configuration
  for Pipeline execution. This commit clarifies that while execution options must be configurable at runtime,
  we may choose to also make them configurable at authoring time.

[jerop]

/assign

[jerop]

thanks for updating the problem statement @lbernick, much clearer now! 🎉

[lbernick]

/assign bobcatfish

[afrittoli]

Thanks for the update on this @lbernick.

The new TEP name seems fine to me, however the summary suggests that the execution mode must be controlled by the user that executes the pipeline.
I'm not convinced that that must be the case though. I agree we might give that control to users, but I would like to consider options where the Tekton controller makes some smart choices based about how execute a pipeline, rather than leaving it to the user by default.

[lbernick]

The new TEP name seems fine to me, however the summary suggests that the execution mode must be controlled by the user that executes the pipeline. I'm not convinced that that must be the case though. I agree we might give that control to users, but I would like to consider options where the Tekton controller makes some smart choices based about how execute a pipeline, rather than leaving it to the user by default.

Thanks for the feedback! I've updated the summary to simply say that we want more options for how to execute pipelines, and tweaked the requirements wording.

[afrittoli]

Thanks for the updates!
/approve

[vdemeester]

/kind tep

[bobcatfish]

I have 2 pieces of feedback but don't need to necessarily block this PR:

1. The new TEP name feels like it's broadening the scope, maybe more than we want to (could interpret it to mean a lot of things) <-- this is the only feedback that's really directly relevant to this PR
2. Re. @afrittoli 's feedback on pipelines making choices on how to execute the pipeline vs the user being explicit, i agree that we should list this as an option however I have my doubts whether the work required to pull that off is worth it, when contrasted with (at least initially) making it possible for the user to be explicit (and laying the ground work for the user to be explicit about how to combine Tasks into pods could make it easier to add this smart grouping later on)

Anyway hoping we can talk some of this through in the API WG on Monday and I'm expecting I'll do an approve shortly after that!

[lbernick]

1. The new TEP name feels like it's broadening the scope, maybe more than we want to (could interpret it to mean a lot of things) <-- this is the only feedback that's really directly relevant to this PR

I've updated the title to "Data Locality and Pod Overhead in Pipelines". A bit long, but this is the closest description I could come up with to the problem we are trying to solve. Makes it clear that the problem is with Pipelines rather than Tasks, doesn't imply runtime vs authoring time configuration, and doesn't expand the scope as much as the previous title.

2. Re. @afrittoli 's feedback on pipelines making choices on how to execute the pipeline vs the user being explicit, i agree that we should list this as an option however I have my doubts whether the work required to pull that off is worth it, when contrasted with (at least initially) making it possible for the user to be explicit (and laying the ground work for the user to be explicit about how to combine Tasks into pods could make it easier to add this smart grouping later on)

I don't think this was completely resolved at the WG, but I also don't think this PR should be blocked on resolving this question.

[bobcatfish]

Thanks @lbernick ! :D For me that's an:

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afrittoli, bobcatfish, jerop, 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 [afrittoli,bobcatfish,jerop,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 to be merged outside of api wg in slack thread

thanks @lbernick!