feat: Implement rebalance queue and config option #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context: In Argo, semaphores are implemented by wrapping Go's semaphore with some additional stuff. At the moment this "additional stuff" is mainly around prioritizing lock distribution to higher-priority workflows first. This can be seen in
semaphore.go
, which shows how the priority queue is utilized intryAcquire
before trying to acquire the lock using the more primitive semaphore.I also recommend checking out sync_manager to get a sense for how semaphores fit into the bigger Argo / Kubernetes picture.
This PR: I want to create a PR that is as low-touch as possible, so we can continue to rebase with Argo as long as possible with as little friction as possible. My approach is to create a new type of queue that can be dropped into
semaphore.go
. This queue will have a new strategy: instead of being a plain old priority queue, we want the queue to distribute locks based on who is currently under-represented in the set of locks that are currently acquired.