argoproj / argoproj/argo-workflows

Option to have workflow with single available lock run

Open
#13,630 3 comments 0 reactions 0 assignees View on GitHub
area/mutex-semaphore
Dominant language
Go
Stars
17k
Forks
3.7k
Avg merge
1d 15h
Merged PRs (30d)
138

Description

# Summary

The multi mutex/semaphore feature has a restriction that only becomes apparent with this feature. Prior to this feature there was only ever one possible mutex or semaphore so in case of highpriority wf and lowpriority wf both wanting it the high one would get it. But in case of high priority wf wanting 2 mutexes (1 which is available but the other taken by some other wf) and different low priority wf only wanting 1 mutex (which is available) the low priority wf is unnecessarily blocked from running even though the high priority can't run anyway (since not ALL of its criteria is met)

see https://github.com/argoproj/argo-workflows/pull/13358#discussion_r1681710287

## Use Cases

This is similar to 'short query acceleration' where small tasks are allowed to get a slice of compute whenever the heavy hitters did not necessarily have enough headroom to run

Contributor guide

Open the contributing guide

Research direction

Start with the multi-mutex/semaphore change and the discussion in pull request #13358, then trace how high- and low-priority workflows are considered when multiple locks are requested. Done means a lower-priority workflow can run when its single available lock is sufficient, even if a higher-priority workflow cannot obtain all of its locks.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.