153f8a90cc
This allows jobs to request multiple semaphores. Zuul will wait until all are available before acquiring them* and will not start a job unless all have been acquired. This is useful for jobs which require access to mulitple limited resources (especially if other jobs require access to a subset or superset of those same resources). * Implementation note: for efficiency, we actually do acquire them one-by-one but then release any which have been acquired if they are not all available. This all happens very quickly within a single attempt to start a job. We don't hold semaphores while we wait for others as that could cause deadlocks. To be consistent with other job attributes which accept lists, this deprecates job.semaphore and replaces it with job.semaphores. Change-Id: I295a891a2d02b904820d8f60afe8ef862693b75d
15 lines
613 B
YAML
15 lines
613 B
YAML
---
|
|
features:
|
|
- |
|
|
A job using a semaphore now can configure if it should acquire the it
|
|
before requesting resources or just before running.
|
|
upgrade:
|
|
- |
|
|
The acquiring behavior of jobs with semaphores has been changed. Up to now
|
|
a job requested resources and aquired the semaphore just before it started
|
|
to run. However this could lead to a high amount of resource waste. Instead
|
|
jobs now acquire the semaphore before requesting the resources by default.
|
|
This behavior can be overridden by jobs using
|
|
job.semaphores.resources-first if some waste of resources is
|
|
acceptable.
|