-
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
resource/aws_instance: vpc_security_group_ids always showing update #1993
Comments
@Yuxael Could you try adding One more thing you would want to verify is that you have a default VPC and a default subnet defined in your account. |
@abinashmeher999 If you look at the debug log you can clearly see that AWS api returns all the informations related to VPC. My account supports only VPC instances, there is only one VPC in that region and it's set as default, security group is associated to this VPC, etc. Also
None of the above worked. |
I'm running into the same issue. main.tf
tfstate file
|
There seems to be PR #1911 which is supposed to fix this, but IMHO it's more of a workaround than fix, as it just changes what is saved in tfstate in |
So does #1911 imply that we should be using a |
My guess is that the author if that PR just made a quick-fix for #1799 that seems to work without actually understanding what's the root of the problem. As you already noticed, it's against everything stated either in docs or by TF guys. There is a very nice explanation how it should work and what are the plans to fix this mess. |
…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
I'm having the same issue, but I found out that it only happens in a region where I have a Default VPC, but no Default Subnet. This seems to confuse Terraform, which requires a security group ID to create an instance, but then (after a In regions where I have both a Default VPC and Default Subnets, it's working correctly: I can specify a security group NAME and the NAME is written to the .tfstate file. |
I'm not sure if that's the same issue; in the VPCs in which I have this issue, my VPCs have default subnets. And I'm not sure if terraform should be dependent on resources that aren't required existing (we have lots of accounts that don't have a "Default VPC" for example). The problem here is that I don't want security group names written to the tfstate file at all; the existing |
Apologies for the long delay -- I have done some further investigation. It is indeed the same issue, but adding a specific Scenario 1: default subnet of a default VPCThe following works for me: resource "aws_security_group" "sg" {
name = "test-sg"
}
resource "aws_instance" "instance" {
ami = "xxxxxx"
instance_type = "t2.nano"
key_name = "my-key"
security_groups = ["${aws_security_group.sg.name}"]
} Note that I am using the name of the SG and I am omitting the This is what the docs used to recommend until May 2016:
The docs have changed in this commit and now state:
cc-ing @catsby who authored that change, he might be able to provide some additional insight. Scenario 2: non-default subnet of a default VPCTrying to use
You might thing that in this scenario you should then use Scenario 3: non-default subnet of non-default VPCIn this scenario, using |
If no subnet_id is specified and a default subnet exists in the Default VPC, the instance will be automatically created in the default subnet. Using SG names instead of IDs should also resolve the issue where `terraform plan` is not clean after a cranehost is created. See this issue for additional details: hashicorp/terraform-provider-aws#1993
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. |
👍 @bflad. Look forward to a fix. Cosmetic annoyance. |
For watchers of all the issues and two PRs here, we are very sorry this got lost in the shuffle. The first PR likely should have been reviewed and potentially merged long ago. Our apologies on dropping the ball here. We have been working really hard to get the backlog under control and organized the last few weeks (e.g. you will notice a lot more repository labels now available and on every open issue so hopefully people can find related issues easier). After some extensive acceptance testing we believe that #2338 will properly handle the issue here, which will be merged with an additional testing commit from me. This will be released in v1.9.0 of the AWS provider, which currently is planned for next week. For those that are able, we would greatly appreciate some additional community pre-release testing to ensure this is backwards compatible with all the configurations out in the wild. Instructions for building this provider yourself and installing it manually are documented in the README.
|
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. |
Still happening here:
|
Hey Brian @bflad
and everytime we run
|
[UPDATE]
And this is working very well with me |
Still reproducible in Terraform v0.12.0, not sure if it's because I don't have a default VPC in my account. |
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! |
This issue was originally opened by @Yuxael as hashicorp/terraform#16411. It was migrated here as a result of the provider split. The original body of the issue is below.
Hi,
I have noticed lately that terraform wants to change instance every time I run
terraform plan/apply
. Specifically, it's showing that instance hasn't got any vpc_security_group_ids attached. I have setvpc_security_group_ids = ["${aws_security_group.external.id}"]
in my tf file, terraform creates this security group, attach it to instance, etc., but for some reason in tfstate this information is saved as shown below:Terraform Version
1.10.0 & 1.10.7
aws provider plugin: 1.0 & 1.1
Terraform Configuration Files
Debug Output
https://gist.github.com/Yuxael/e39a652084695c90fde549a0dcd42640
Expected Behavior
terraform plan/apply
should show no changes.Actual Behavior
Steps to Reproduce
terraform init
terraform plan
terraform apply
terraform plan/apply
Important Factoids
tfstate samle:
The text was updated successfully, but these errors were encountered: