Bug: Autoscaling Group Initial Instance not attaching ENI & other fixes #5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Bastion Module Bug
Fixed an issue with the Bastion module where the EIP was being attached before the instance was available
Autoscaling Group Bug
Fixed an issue where the autoscaling group was not provisioning the initial instance using the lambda to attach the second ENI. This was due to a race condition where the lambda IAM policy was waiting for the ASG to fully spin up its first instance prior to assigning the role to the lambda. By the time the ASG finished, it was too late to run the lambda on the first instance.
wait_for_capacity_timeout = 0
was added so the TF module does not wait for the first instance to be provisioned and provides the lambda IAM policy with the ASG ARN before the first instance is created. Also moved the lifecycle hook into the ASG config as theinitial_lifecycle_hook
so that it will be triggered on the first instance provisioned.Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Deploy several times with local version of the code. It consistently deployed all resources correctly