d616ec9d9a
The idea here is * all prod jobs are parented to the boostrap-bridge job (they have a hard dependency on this job). * the bootstrap-bridge job checks out the system-config source to the right place (the commit for a change, master HEAD for periodic). This was actually implemented in a prior change. We're just taking full advantage of it here. * bootstrap-bridge pauses once bridge is setup to the right place * the child jobs now don't have to worry about cloning system-config; they can be sure that it's at the right place for them. they just need keys so their executor can log into bridge and run the playbooks against the production hosts * the bootstrap-bridge job is paused with a semaphore stopping any other runs jumping in. in deployment, zuul is ordering it for us anyway. so really this is stopping conflicts with the periodic jobs. * in theory - all the child production jobs could run in parallel while the boostrap jobs waits for them (modulo dependencies they have expressed; e.g. needing letsencyrpt or backup jobs to have run). To begin with we limit this with a second semaphore with a limit of 1. We can roll this out and check things mostly operate as they did before then bump the max value on this semaphore upwards to run things in parallel. * does this work? I have no idea :) it seems difficult to test outside production because in the testing side everything is its own little world, there's no overarching bootstrap job. Depends-On: https://review.opendev.org/c/opendev/base-jobs/+/942740 Change-Id: I7d2c4737f900c9b964855c4d03ca58a2de2d60b3
12 lines
182 B
YAML
12 lines
182 B
YAML
- hosts: localhost
|
|
roles:
|
|
- add-bastion-host
|
|
|
|
- import_playbook: ../bootstrap-bridge.yaml
|
|
|
|
- name: Wait for child jobs
|
|
zuul_return:
|
|
data:
|
|
zuul:
|
|
pause: true
|