-
Notifications
You must be signed in to change notification settings - Fork 232
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
Plan: diff output not efficient #256
Comments
Hi @sylr! Sorry for this odd diff presentation. Terraform is behaving this way because the provider has told Terraform that this argument is represented by a set, and thus the elements in the set are identified only by their contents and not by any other identifier such as a list index or map key. As a consequence, changing any part of one of these elements in the configuration is interpreted by the provider (and thus, in turn, by Terraform itself) as removing the old object and adding a new object; there is no external identifier to use to correlate these to understand that it's an edit. I expect there's a good reason why the provider team marked this as being a set. Usually this is because the remote system (in this case, Azure) itself treats it as a set, and thus the provider would otherwise have no way to correlate objects in the configuration and state with objects in the remote system. Since these objects seem to have a unique
The new provider protocol in Terraform 0.12 includes support for this, but the Terraform SDK doesn't currently make it available for providers because it is still limited by the Terraform 0.11 protocol while Terraform 0.11 is still supported. Work is starting now on a new version of the SDK that is built around the Terraform 0.12 featureset, and once that is complete the Azure provider team could potentially adopt the feature for this particular block so that a configuration like the above would work and Terraform would track create/update/delete by correlating by those labels. I'm going to ask our bot to record this in the AzureRM provider repository, because ultimately making use of this feature will require an AzureRM provider code change to use it. For the moment though, this remains blocked on the provider SDK work I mentioned above and on the AzureRM provider adopting that new SDK for this particular resource type. For that reason, I expect that in the near term the issue will serve as a placeholder for the potential future work rather than something that can be acted on immediately. Thanks again for reporting this! |
This issue has been automatically migrated to hashicorp/terraform-provider-azurerm#3841 because it looks like an issue with that provider. If you believe this is not an issue with the provider, please reply to hashicorp/terraform-provider-azurerm#3841. |
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
I believe this is a duplicate of #220 (support for named blocks). |
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Terraform Version
Terraform Configuration Files
Origin:
Target:
Only rule2 name has been modified
Expected Behavior
Actual Behavior
The text was updated successfully, but these errors were encountered: