Add warm pool with new ASG lifecycle hooks #966
Closed
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.
Builds on the lifecycle hooks added in #964 and incorporates the warm pool configuration from #838.
Makes the boothook lifecycle hook conditional on the use of warm pool so that instances once again always start the agent on instance boot, unless warm pool is enabled. When warm pool is enabled, we delay agent start until the boothook triggered by the instance moving to InService.
This also changes how we parse the
InstanceType
parameter and adds anInstanceTypes
count parameter. Warm pool is incompatible withMixedInstanceTypes
so we need to be able to switch the Auto Scaling group resource between a staticLaunchTemplate
reference and aMixedInstanceTypes
specification. Warm pool only supports single instance type, and on-demand instance types, using either precludes the use of an ASG warm pool. Adding the count parameter is copied from the AWS VPC Quick Start which uses a similar pattern.TODO
Rule
added to prevent incompatible options across spot, multiple instance types, and warm poolwait
command for Windows instances that theBootHookWarmedAutomation
can use to wait for ec2config, or decide that Windows instances don’t get Warm Pool support and block it using a CloudFormation templateRule
😢InstanceStorage
setting interoperates with 'stopped' EC2 instances. Since the warm pool instances are stopped and re-started, they will come up on new hardware without initialised NVMe drives. If this is irreconcilable these might be incompatible options which should be disabled using a templateRules
entry.BootHook
HeartbeatTimeout
property. This is statically 5 and 10 minutes for Linux and Windows respectively right now. Presently the same launch hook is used for both Warm Pool launch events, direct to ASG launch events, and Warm Pool to ASG launch events, meaning they all have the same timeout applied. We likely want to apply distinct timeouts to each type of lifecycle movement. Launched into the warm pool the timeout should be enough for the UserData script to run to completion, launched directly into the ASG the timeout should be enough for the UserData script and the agent to start, and transitioned from the Warm Pool into the ASG should just be enough to start the agent.