You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Changing the value of a Resource Tag shouldn't cause unrelated values to change (ie. resource name). A subsequent apply should simply update the Tag and custom_data should not change.
Step 1)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.0' ... Plan: 8 to add, 0 to change, 0 to destroy.
Step 2)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.1' ... Plan: 0 to add, 6 to change, 0 to destroy.
Actual Behavior
Step 1)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.0' ... Plan: 8 to add, 0 to change, 0 to destroy.
Step 2)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.1' ... Plan: 1 to add, 5 to change, 1 to destroy.
We're currently working on version 2.0 of the Azure Provider which we previously announced in #2807.
As a part of this we're introducing five new resources which will supersede the existing azurerm_virtual_machine and azurerm_virtual_machine_scale_set resources:
azurerm_linux_virtual_machine
azurerm_linux_virtual_machine_scale_set
azurerm_virtual_machine_scale_set_extension
azurerm_windows_virtual_machine
azurerm_windows_virtual_machine_scale_set
We recently opened #5550 which adds support for the new Virtual Machine resources - and I'm able to confirm that this is fixed in the new Virtual Machine resources - however unfortunately we have no plans to backport this to the existing azurerm_virtual_machine resource.
In order to get feedback on these new resources we'll be launching support for these new resources as an opt-in Beta in an upcoming 1.x release of the Azure Provider and ultimately release these as "GA" in the upcoming 2.0 release. We'll post an update in #2807 when both the opt-in Beta (1.x) & GA (2.0) are available - as such I'd recommend subscribing to that issue for updates.
This issue's been assigned to the milestone "2.0" since this is where this will ship - however (due to the way that closing Github Issues from PR's works, to be able to track this back for future users) this issue will be closed once the first of the new resources have been merged.
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. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
ghost
locked and limited conversation to collaborators
Mar 5, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There appears to be an issue when updating the Tags of resources that are referenced in a custom_data template that is causing the VM to be replaced.
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
azurerm_virtual_machine
data.template_cloudinit_config
Terraform Configuration Files
Debug Output
Panic Output
Expected Behavior
Changing the value of a Resource Tag shouldn't cause unrelated values to change (ie. resource name). A subsequent apply should simply update the Tag and
custom_data
should not change.Step 1)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.0'
...
Plan: 8 to add, 0 to change, 0 to destroy.
Step 2)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.1'
...
Plan: 0 to add, 6 to change, 0 to destroy.
Actual Behavior
Step 1)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.0'
...
Plan: 8 to add, 0 to change, 0 to destroy.
Step 2)
$ terraform apply -var-file my.tfvars -var 'project_version=v0.1.1'
...
Plan: 1 to add, 5 to change, 1 to destroy.
Steps to Reproduce
terraform apply -var-file my.tfvars -var 'project_version=v0.1.0'
terraform apply -var-file my.tfvars -var 'project_version=v0.1.1'
Important Factoids
Putting the Resource reference in a Locals variable works around the issue.
References
The text was updated successfully, but these errors were encountered: