-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
instances always need vpc_security_group_ids updated #1799
Comments
Upgraded TF from 0.9.11 to 0.10.7.
Always shown as to be updated. |
I still have the issue after upgrading to Terraform 0.10.7. |
ran into the same issue today with Terraform v0.10.7 |
Same issue here. |
Same issue here. #1911 definitely fixes it! Hope it gets merged soon. |
…urity_group_ids Unlike instances launched into a default VPC are allowed to refer to their security groups by ID, like other VPCs, or by name, like EC2-Classic. The current implementation of the function that reads instance security group data assumes that instances in a default VPC refer to their security groups by name. This causes an instance resource that is launched in a default VPC but using the `vpc_security_group_ids` parameter (instead of the `security_groups` parameter) to always have a diff in plans post-creation showing that the security groups need to be added to it. This commit changes the behavior of the function that reads instance security data to be able to store BOTH the security group names and IDs in the case of an instance in a default VPC. Because both the `security_groups` and `vpc_security_group_ids` parameters are marked as "computed", it's valid to provide either in the resource configuration even though both will end up in state. This commit also adds a failing test for the case of using `vpc_security_group_ids` with a default VPC, and ensures that both default VPC import tests are run in a region with a default VPC (which specifically must _not_ be an EC2-Classic region). Fixes hashicorp#1799 Fixes hashicorp#1993
Same issue exists in v0.11.1. |
Hi everyone! Sorry you have been having trouble with this Due to the high volume of reports surrounding this, the maintainers will be looking into this sometime in the near future (including the already open PRs: #1911, #2338). There are some nuances around this configuration that make it harder than a quick fix and we certainly do not want to make the situation worse. We'll keep you updated. As a friendly reminder: voting with 👍 reactions on the original issue/PR comment is the best way to get our attention. |
This has been released in terraform-provider-aws version 1.9.0. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Terraform Version
Terraform v0.10.6
AWS plugin: aws_v1.0.0_x4
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/clippermadness/7993969b9b8bdda2883f89fdf9c9456a
Steps to Reproduce
The text was updated successfully, but these errors were encountered: