CORS-1704 removed some hard-coded zone choices, but leaves us with the following buggy blackhole flow:

1. ipi-conf-aws, which since CORS-1704 is trying to be clever about picking zones.
2. ipi-conf-aws-blackholenetwork , which is consuming a zone count and then picking the first $COUNT zones for that region, even if ipi-conf-aws had a different $COUNT zones in mind.

We could fix the blackhole step's inline CloudFormation, but the shared network chain has a similarly buggy order, and it is curl-ing down its CloudFormation template from the installer's master branch . So not something we can narrowly fix in the release repo, hence this ticket.

One option would be to make the two CloudFormation templates more flexible, so you could feed them a set of chosen zones, instead of just the count. The downside to that is that the installer's template is quasi-user-facing, and while I don't think we have strict backwards-compat requirements around that API, any time we change something that touches openshift-docs we should be careful.

Another option is to follow the spirit of the pre-existing infra more closely, and create that pre-existing infra before we start in on the install-config. That might involve splitting an ipi-conf-aws-from-pre-existing out of ipi-conf-aws and then duplicating the "which zones do I like?" logic between ipi-conf-aws, ipi-conf-aws-blackholenetwork, and ipi-conf-aws-sharednetwork, or pulling them out into a new ipi-conf-aws-zone-selector step.

Until we do something in this space, expect the proxy and shared-network jobs to be pretty dead.