-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
None
-
Quality / Stability / Reliability
-
False
-
None
-
False
-
None
-
5
-
None
-
None
-
Sprint 200, Sprint 201, Sprint 202
Related cards: https://issues.redhat.com/browse/DPTP-2102
Currently, the ipi-conf-aws step can run under a specific AWS account. Recently another AWS project has been created for the same purposes but the step fails to run.
Some of the main reasons are:
- The current version of the script hardcodes the availability zones, but they differ between different accounts.
- The current image that is being used by the script doesn't include an `aws` command.
- These scripts hardcode dependencies that are related to a specific AWS account: ipi-conf-aws-commands.sh ipi-conf-aws-blackholenetwork-commands.sh ipi-conf-aws-proxy-commands.sh
Workaround suggestions by mstaeble:
- Don't rely on pre-created VPCs but instead, we could have the steps create a new VPC and other necessary resources as needed.
- Add `awscli` command to step image:
- Use the UPI CI image, which already has the `aws` command.
- Or install `awscli` as part of the step.
- We should be able to use a random subset of availability zones, in general, rather than hard-coding specific availability zones. This would require querying AWS for the list of AZs available in the region for the account being used. For cases where the steps are using pre-existing resources that are bound to specific AZs, such as subnets, then the steps would need to query AWS for the details of those resources to determine which availability zones must be used.
- is related to
-
CORS-1730 Create subnets in the chosen zones for shared-subnet and proxy workflows
-
- Closed
-
- links to