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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(ecs-patterns): adding support for custom HealthCheck in NetworkLoadBalancedFargateService #21083
feat(ecs-patterns): adding support for custom HealthCheck in NetworkLoadBalancedFargateService #21083
Changes from 2 commits
89c538b
9c4f205
76b9634
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After thinking about this more, I'm not sure we should expose this on the top level props. For an ECS service there behind a load balancer there are two different types of health checks that you can use.
I'm not sure this is a common use case for services running behind an ELB. The other linked PR that implemented this for the QueueProcessing service makes more sense because it is a worker service that is not running behind an ELB so container health checks are the only type of health check available.
I think in the majority of cases the user wants to configure the ELB health check and exposing this at the top level (an not the elb health check) would lead to more confusion and users configuring container health checks when they don't need to.
cc @madeline-k for a second opinion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@corymhall Ok I think this makes sense. Maybe we should close this (and the linked issue) and come up with a solution if there is a real need for this. And even then explicitly document the consequences.
And I want to apologize for implementing this feature without really thinking about it. I will try to go more in-depth in a topic I will implement in the future.