-
-
Notifications
You must be signed in to change notification settings - Fork 628
feat: Allow specifying VPC ID used by service security group in lieu of deriving from subnets provided #353
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: Allow specifying VPC ID used by service security group in lieu of deriving from subnets provided #353
Conversation
81eac13
to
4d16e1f
Compare
Hey @antonbabenko 👋 I submitted this PR to improve the service module. When you have a few minutes, it'd be super cool to have your review 😸 Thanks a lot. |
Do you have a reproduction of the issue? |
Hi @bryantbiggs 👋 Yeah, this issue is triggered when you upgrade from AWS provider v5 to v6. I was able to reproduce the issue from this repository on one of my accounts with
|
you can work around that with: terraform apply -target='module.ecs_service.data.aws_subnet.this[0]' \
-target="module.ecs_service.data.aws_caller_identity.current" \
-target="module.ecs_service.data.aws_partition.current" \
-target="module.ecs_service.data.aws_region.current" \
-target="module.ecs_task_definition.data.aws_caller_identity.current" \
-target="module.ecs_task_definition.data.aws_partition.current" \
-target="module.ecs_task_definition.data.aws_region.current" that ensures any data sources have been updated before proceeding with resource updates. data sources are updated due to the new AWS provider version ( |
to be clear, you are migrating across a major version of both the module as well as the AWS provider which both are breaking changes. we aim to minimize disruption as much as possible but it is not guaranteed - some manual intervention may be required during upgrades |
This may be due to the migration to version 6 in this case but we had this bug before with AWS provider v5 and we had to fork this repository to fix the issue by adding a vpc_id input. I'll try to provide you a reproduction of this problem. |
I also experiment the issue sporadically, but unsure what causes it (I thought it could be due to the ordering of It is slightly annoying when it happens as terraform re-creates the ECS service as well. |
any update on a reproduction? is |
Sometimes, it happens that Terraform tries to recreate the security group of the ECS service whereas the VPC did not actually change. To avoid this issue, let's use the dependency inversion principle (described here https://developer.hashicorp.com/terraform/language/modules/develop/composition#dependency-inversion) by passing the VPC ID as an input.
4d16e1f
to
139222e
Compare
## [6.6.0](v6.5.0...v6.6.0) (2025-10-01) ### Features * Allow specifying VPC ID used by service security group in lieu of deriving from subnets provided ([#353](#353)) ([ac8f420](ac8f420))
This PR is included in version 6.6.0 🎉 |
Hi @bryantbiggs. Sorry for the delay, I'm currently on vacation, I was not able to reproduce the issue with AWS provider version. 6 yet. Anyway, thanks a lot for merging this new feature. It will allow us to avoid the problem if it comes back. |
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.
Hello! I ran into an issue tonight when deploying, and I just realized this was newly released. I think there is an issue with the default logic.. I was migrating services and a security group ended up being created in the default VPC and not the correct VPC (where the subnets are located). It took me a while to figure this issue out.. I managed to fix it by specifying the VPC manually but I think this breaks otherwise.
name_prefix = var.security_group_use_name_prefix ? "${local.security_group_name}-" : null | ||
description = var.security_group_description | ||
vpc_id = data.aws_subnet.this[0].vpc_id | ||
vpc_id = try(data.aws_subnet.this[0].vpc_id, var.vpc_id) |
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.
This should be the other way around
vpc_id = try(data.aws_subnet.this[0].vpc_id, var.vpc_id) | |
vpc_id = coalesce(var.vpc_id, data.aws_subnet.this[0].vpc_id) |
|
||
data "aws_subnet" "this" { | ||
count = local.create_security_group ? 1 : 0 | ||
count = local.create_security_group && var.vpc_id != null ? 1 : 0 |
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.
count = local.create_security_group && var.vpc_id != null ? 1 : 0 | |
count = local.create_security_group && var.vpc_id == null ? 1 : 0 |
And this only when we don't set the vpc_id
I think you should provide a reproduction before assuming - makes it easier to triage 😬 |
Sometimes, it happens that Terraform tries to recreate the security group of the ECS service whereas the VPC did not actually change.
To avoid this issue, let's use the dependency inversion principle (described here https://developer.hashicorp.com/terraform/language/modules/develop/composition#dependency-inversion) by passing the VPC ID as an input.
Before this MR, here is what could happen during the plan:
Because Terraform needs the datasource
aws_subnet
to get the VPC ID, it forces the replacement of theaws_security_group
. Passing the VPC ID as input of the module fixes this issue.How Has This Been Tested?
examples/*
to demonstrate and validate my change(s)examples/*
projectspre-commit run -a
on my pull request