Add support for setting the Availability Zone to support AWS resource… #38
Conversation
…s that are not available in all zones within a region
jaredhocutt
left a comment
jaredhocutt
left a comment
There was a problem hiding this comment.
As you have it here, this forces people to choose a zone which isn't desirable. For most users, we want it to randomly choose a zone.
To fix this, anywhere you're using the aws_zone variable, use it like this:
zone: "{{ aws_zone | default(omit) }}"| - name: Delete EC2 instances | ||
| ec2_instance: | ||
| region: "{{ aws_region }}" | ||
| availability_zone: "{{ aws_zone }}" |
There was a problem hiding this comment.
You shouldn't need to limit by availability zone here as it should still find the EC2 instances to delete. You can remove it.
| filters: | ||
| tag:OpenShiftClusterName: "{{ cluster_name }}" | ||
| tag:OpenShiftClusterNameVerbose: "{{ cluster_name_verbose }}" | ||
| availability-zone: "{{ aws_zone }}" |
There was a problem hiding this comment.
You shouldn't need to limit by availability zone here either.
|
Make sense. I'm not a huge fan of the fact that git lets you manipulate history and I meant to add all of this to a branch in case I needed to make edits which is much easier to do in a PR with a branch. Do you mind if I close this PR, add the original changes, along with your modification requests, to that branch, and then create another PR from there? Sorry for the trouble. It has always bugged me that a revision control system like git lets you change history even when there is a mistake. |
|
Just make the changes and add as a new commit on your master. It'll automatically update the PR for you and I can squash merge when I accept the PR. |
… file. Make default AZ setting random. Remove AZ setting from tasks that do not require it
|
OK. I made the changes:
|
|
Can you run a test deployment by not setting Thanks! |
|
Sure. I'm going to pull the repo fresh and just run it. |
2 participants
Add support for selecting the Availability Zone in AWS. Not all resources in AWS are available in each zone of a region. Current example being GPU instances. They are available in us-east1-a/c/f but not b. Without this setting it is generally random what Availability Zone the instances end up in.