Support ignoring changes to staging_storage_account_id on azurerm_site_recovery_replicated_vm

hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs

Mozilla Public License 2.0

4.52k stars 4.6k forks source link

Support ignoring changes to staging_storage_account_id on azurerm_site_recovery_replicated_vm #18703

Open jdaugherty opened 1 year ago

jdaugherty commented 1 year ago

Is there an existing issue for this?

[X] I have searched the existing issues

Community Note

Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

When managing site recovery using the azurerm_site_recovery_replicated_vm resource, the staging_storage_account_id is set on the initial create. After failing over the VM, the staging_storage_account_id is changed by Azure, which causes terraform to recreate the resource. The site recovery is still configured and works. Is it possible to add support for not refreshing the resource if the staging_storage_account_id changes?

New or Affected Resource(s)/Data Source(s)

azurerm_site_recovery_replicated_vm

Potential Terraform Configuration

No response

References

No response

ziyeqf commented 1 year ago

Hi @jdaugherty , thanks for reporting. Accroding to the description, I may suggest to use ignore_change to ignore the staging_storage_account_id prop chaning like the following.

resource "azurerm_site_recovery_replicated_vm" "example" {
  # ...

  lifecycle {
    ignore_changes = [
      managed_disk
    ]
  }
}

The reason is that changing this prop (staging_storage_account_id) will force a new resource created, and the provider can't tell wether the diff is caused by user changing the config or by the Azure.

But, I have tried to crate an azurerm_site_recovery_replicated_vm resource and triggered "failover" manually via Portal, and the staging_storage_account_id did not change. Could you please provide more details about how the situation formed so that I can dig further?

mpjtaylor commented 1 year ago

have an issue with staging_storage_account_id where in its /storageaccounts/ and then /storageAccounts/ this causes a recreation of DR

mpjtaylor commented 4 months ago

Does this not need support for Target storage account , ignoring the managed disk is not a good idea at all any disks changes to the virtual machine will not update the replication.