-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
aws_security_group does not destroy rules when all nested blocks are removed #11059
Comments
Just added a new test case for your issue: see this repository |
Putting tests in DEBUG mode show some strange things (from my perspective) when calling HasChange in resourceAwsSecurityGroupUpdateRules
=> HasChange false which seems OK to me but this is using the Equal function defined in However when re-reading existing security group (plan/update)
and
gives HasChange = true which is definitely wrong !!! and this because here, due to the more nested aspect of the object, DeepEqual is used and therefore returns a "wrong" value due to This is using reflect.DeepEqual so this is even weirder to me but may be someone very knowledgeable with Terraform code could explain it. |
Further deep checking after deriving reflect library code and adding debug statements to it, indeed showed that reflect.DeepEqual returns false at the very first pointer difference and therefore because of the |
Note that, also as stated above, the 2 completely empty objects are also DeepEqual false because of the very first addresses which differ: therefore, I understand why Equal function in set.go is used because it 'skips' this 1st level: see this line of code as reference |
In fact, I also found out that because of this line in reflect.DeepEqual the test fails where it should not. Ih have therefore logged an issue for a potential trivial fix against go |
In fact, experiencing more on this issue, the cases where there are nested schema.Set structures completely annihilates the purpose of set.Equal function which only works at level 1 |
Similarly, if an ingress/egress rule is added outside of TF directly in AWS, refreshing the state will not notice this addition and no change will be necessary in your plan. |
Hey @mattvanstone 👋 Thank you for taking the time to file this issue. This may require a newer version of the AWS provider, but these blocks are now processed as attributes as blocks. With that in mind, the attributes as blocks documentation talks about explicitly calling zero objects by passing something like |
I think this is just #1555, but slightly more generic to also include |
This functionality has been released in v5.8.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
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. |
Community Note
Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/mattvanstone/3cbe440a17ca30f2b4e836b5feceec3b
Expected Behavior
When you deploy an aws_security_group with nested ingress or egress rules, then remove all the rules from the code and reapply the the infrastructure should be updated by removing the rules.
Actual Behavior
If you remove all of the egress or all of the ingress rules the provider ignores all existing rules in the state, leaving them in place in the infrastructure. If you have at least one rule then the provider will remove all of the other rules as expected.
Steps to Reproduce
terraform apply
terraform plan
orterraform apply
This will result in
No changes. Infrastructure is up-to-date.
when it should remove the rules.Important Factoids
References
The text was updated successfully, but these errors were encountered: