Open ahg-g opened 2 years ago
Can someone remove "Tekton" from the title of this issue?
Ideally, the mechanism should be extensible to Tekton and any other workflow manager. But certainly, we can start with just Argo.
Ideally, the mechanism should be extensible to Tekton and any other workflow manager. But certainly, we can start with just Argo.
+1 this should be aligned with other workflow tools as well, from kueue side.
Ideally, the mechanism should be extensible to Tekton and any other workflow manager. But certainly, we can start with just Argo.
I understand. In that case, this component should aim to minimize its dependencies on modifications to other workflow managers.
Not necessarily. But it should aim at modification that could be feasible in other projects. Just like we did the suspend
field for Job that could be replicated in projects such as kubeflow and kuberay.
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
This is lower priority than https://github.com/kubernetes-sigs/kueue/issues/65, but it would be good to have an integration with a workflow framework.
Argo supports the suspend flag, the tricky part is that suspend is for the whole workflow, meaning a QueuedWorkload would need to represent the resources of the whole workflow all at once.
Ideally Argo should create jobs per sequential step, and then resource reservation happens one step at a time.