Update desired count behavior #194
Open
+134
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hello!
We've noticed that during a deployment, the DesiredCount will always end up being managed by CloudFormation due to it's presence in the template. We tried removing this using an escape hatch but that caused another issue with the way the scheduling strategy of REPLICA works. When you use REPLICA, you're required to pass in a desired count on create, but on update it can be omitted as it is already present on the ecs service itself. In this PR we simply removed the need for the DesiredCount to be in the generated CloudFormation template, and simply enforce it's default of 1 in the custom resource Create handler itself. This implementation will be flexible enough to still pass in a desired count whenever you please!
Best,
Roger