Open sean-freeman opened 2 years ago
Hi @sean-freeman , rules is a computed attribute in ibm_is_security_group and ibm_is_vpc resources, so when a standalone security group rules resource is declared and provisioned, these rules are set in the computed 'rules' field of security group and VPC resources in the next apply.
Hi @sean-freeman can this be closed ?
@deepaksibm It should remain as a backlog item.
The ibm_is_vpc
and ibm_is_security_group
resources have computed field 'rules', and if there is subsequent usage of the standalone ibm_is_security_group_rule
(which is dependent on the VPC and SG existing).... it makes sense that the computed field would be updated with those rules.
However, there should be a smarter way of handling this update. The text from Terraform runtime states Terraform detected the following changes made outside of Terraform since the last "terraform apply"
. This is confusing to the end user, who might believe their account has been hacked/compromised/altered. In addition, it provides a LOT of extra output.
Alternative suggestions to avoid this situation:
ibm_is_security_group_rule
in the TF State File will be ignoredibm_is_security_group_rule
in a Terraform Module/Template, update Terraform Resource ibm_is_vpc
and ibm_is_security_group
Affected Resource(s)
Expected Behavior
Output should not show security group rules unless the rule has changed.
Actual Behavior
When Security Group Rule standalone Terraform Resources are declared, there is significant output on subsequent runs where
is_security_group
andis_vpc
have nested in-line rules:Steps to Reproduce
terraform apply
terraform plan
OR changes made to TF Resources (not security group rules) +terraform apply