limit concurrent jobs per worker to 1?

[x3nb63]

is that possible?

My problem is testing kernel drivers and hardware behavior on Windows. There can be only one at a time.

With CONCOURSE_TAG I dont see how to accomplish this, cause there are multiple pipelines doing these things. So I actually want them all be waiting for a single machine and run one after the other.

[taylorsilva]

I don't think the following is a solution for you, but here's some related info anyways.

You can use the container placement strategy limit-active-tasks but this is a cluster-wide setting, it's not worker specific... From the concourse web --help:

--container-placement-strategy=[volume-locality|random|fewest-build-containers|limit-active-tasks]
Method by which a worker is selected during container placement. (default: volume-locality)
[$CONCOURSE_CONTAINER_PLACEMENT_STRATEGY]

--max-active-tasks-per-worker= 
Maximum allowed number of active build tasks per worker. Has effect only when used with
limit-active-tasks placement strategy. 0 means no limit. (default: 0)
[$CONCOURSE_MAX_ACTIVE_TASKS_PER_WORKER]

Again, this is a cluster-wide setting. You're telling Concourse the max tasks for all workers. There's currently no way to say "for this one worker only run one task at a time". Maybe this strategy could be modified to allow workers to advertise how many tasks they can accept, overriding the web's value. Would be a neat feature!

I would recommend serial_groups but I see that your problem is across pipelines :(

[chenbh]

Would this be possible with tagged workers and max-containers? You should be able to set max-containers=1 to restrict the number of containers that can run on it. However I don't remember if tagging a worker will stop check containers from being created on it.

EDIT: Nvm, max-containers is a configuration option on guardian, which doesn't apply since Windows workers use houdini

[x3nb63]

the cluster-wide container placement strategy sounds feasible to me, cause my Linux workers are run by Kubernetes so I can have it start multiple ones per machine, I guess.

Will try, thanks.

... that feature would be cool however, ie. to tweak to the number of hardware cores or memory channels, disks or whatever the actual bottleneck of the jobs is. Licenses ...

EDIT: I used to work with slurm and implemented a lot such things using its license tracking, Consumable Resources and Resource Limits - some set of these were always necessary to get the hardware running close to 100% speed really, cause blunt overcommiting usually slows everything

[DanielJonesEB]

Could you possible use some combination of the pool resource and some sort of dynamically-emitted metadata? You'd need to have the same 'gate' at the beginning of every pipeline (not just your own) that would claim a lock from the pool that represents the worker. You'd then need to work out how to get a job to figure out which worker it's on, and then claim that lock. Any subsequent jobs in the pipelined would be passed this resource to ensure they only run when the lock is claimed.

[x3nb63]

Could you possible use some combination of the pool resource and some sort of dynamically-emitted metadata?

i'll look into that too, thanks!

so far I have no progress on this because of other contruction sites with all the pipelines I need to create ... I will report here.

[x3nb63]

the limit-active-tasks placement strategy has the desired effect.

I argue the "no parallel tasks on Linux workers" with "higher task throughput of the cluster". It appears our workers stall a lot on local I/O during container image pulls. That appears to be more smooth now.

The pool-resource approach is looks to complex to me ... also I wanna keep the pipelines as self-contained as possible. I may get back to it ...