bflad
commented
5 years ago Hi @jbscare 👋 Does it work if you combine the two rules with matching ports and protocol?
{
"provider": {
"aws": {
"__DEFAULT__": {
"assume_role": {
"role_arn": "arn:aws:iam::798732171007:role/admin"
},
"profile": "chargeup",
"region": "us-east-1",
"version": "~> 1.57.0"
}
}
},
"resource": {
"aws_security_group": {
"group-x": {
"description": "Managed by Terraform",
"egress": [],
"ingress": [],
"name": "group-x",
"vpc_id": "vpc-9bffd1fe"
},
"group-y": {
"description": "Managed by Terraform",
"egress": [],
"ingress": [
{
"from_port": 8989,
"protocol": "tcp",
"security_groups": [
"${aws_security_group.group-x.id}"
],
"to_port": 8990
},
{
"cidr_blocks": [
"10.192.22.52/32"
],
"self": true,
"from_port": 8989,
"protocol": "tcp",
"to_port": 8990
}
],
"name": "group-y",
"vpc_id": "vpc-9bffd1fe"
}
}
}
}For historical reasons to match the EC2 API, the Terraform AWS provider should try to combine rules in that manor. Can you let us know? Thanks!
jbscare
nurpax
muresan
github-actions[bot]
Community Note
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/jbscare/6918964f0500c71e3c25560b731e5a4f
Panic Output
No panic output.
Expected Behavior
After applying this config, a second
terraform apply(or aterraform plan) should show that no changes are needed.Actual Behavior
The second
terraform applyshows that it still wants to make changes. Usingterraform planand a pipe to sed to show only the things that it wants to change:That is, it wants to remove ingress.9858312, which contains a CIDR block and a security group, and replace it with ingress.210426432 containing the security group and ingress.2277696117 containing the CIDR block.
Applying the change doesn't seem to change the state; it continues to think it needs to apply this exact change.
Steps to Reproduce
NOTE that this doesn't consistently reproduce the problem. If it doesn't, try
It often reproduces the problem after only one or two tries, but I've sometimes had to try as many as a dozen times.
Important Factoids
We use IAM roles to apply our configs.
If you get to a point where you can reproduce the problem, you can eliminate the problem by changing any of the parameters in the config. For example, if you:
Then a
terraform applycommand will apply the change, and a secondterraform applycommand will say there are no changes.If you then put the config back to the original parameters,
terraform applywill go back to continuing to think there are changes ever after applying.We suspect that the reason it doesn't always reproduce is that the security group ID is also signficant, and that some SG IDs trigger the problem while some don't. Unfortunately, that's not a parameter you can just change in your config.
In our testing, we found that these pairs of security group IDs did reproduce the problem:
aws_security_group.group-x: Creation complete after 1s (ID: sg-0a92d7e18ae410e22) aws_security_group.group-y: Creation complete after 1s (ID: sg-0a3cc8872feb026da)
aws_security_group.group-x: Creation complete after 1s (ID: sg-01172b325c5570bda) aws_security_group.group-y: Creation complete after 1s (ID: sg-0007241960f06f4a0)
aws_security_group.group-x: Creation complete after 1s (ID: sg-05c9cc7e76b83e419) aws_security_group.group-y: Creation complete after 1s (ID: sg-0b5b97a5d904f9ca2)
While these combinations did not reproduce the problem:
aws_security_group.group-x: Creation complete after 1s (ID: sg-0eaa35cb65915d1f8) aws_security_group.group-y: Creation complete after 1s (ID: sg-0063137ed8d0db6c8)
aws_security_group.group-x: Creation complete after 1s (ID: sg-0e7b0209bcbc66d83) aws_security_group.group-y: Creation complete after 1s (ID: sg-07c0f432f1a920bf0)
aws_security_group.group-x: Creation complete after 1s (ID: sg-0f985965ac7712fb8) aws_security_group.group-y: Creation complete after 1s (ID: sg-0813d8604667c8371)
aws_security_group.group-x: Creation complete after 1s (ID: sg-0d37d705636acc7fb) aws_security_group.group-y: Creation complete after 1s (ID: sg-0c66b0c05258f92f0)
aws_security_group.group-x: Creation complete after 1s (ID: sg-0ebfed8677b378e81) aws_security_group.group-y: Creation complete after 1s (ID: sg-0f389437a07360b42)
aws_security_group.group-x: Creation complete after 1s (ID: sg-0d83646a14c0e3f30) aws_security_group.group-y: Creation complete after 1s (ID: sg-0e28c2ecea3dac365)
Just in case there's some pattern there (we're not seeing one, but who knows).
I really wanted to title this bug "A CIDR, a SG, and self=true walk into a bar", but managed to resist.
References
None.