argoproj / argoproj/argo-workflows
Change from using pod status to mainly just task-result
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 138
Description
Currently, we use a mixture of pod status and task-result to determine the outcome of a workflow step. Pods can be deleted as soon as they complete and so it is possible for the pod status to be lost before the controller can update the node status. This happens a lot during node drain, resulting in "pod deleted" workflows.
Instead:
* The wait container could populate the task-result with phase and message.
* Task-result should be owned by workflow, not pod.
Combined, this means that the outcome of the step will linger until the controller can capture it.
Contributor guide
Research direction
The issue names no files, tests, or entry points. Start by tracing how the wait container writes task-result and how the workflow controller reads pod status and task-result. Done means the step phase and message remain available after pod deletion and the controller uses the workflow-owned task-result to determine the outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100