Terraform-provider-azurerm: azurerm_security_center_contact errors on create, but creates the contact without saving state

[max-mayrhofer]

Community Note

• Please vote on this issue by adding a 👍 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

Terraform (and AzureRM Provider) Version

Terraform 0.12.24
AzureRM >=2.3

Affected Resource(s)

• azurerm_security_center_contact

Terraform Configuration Files

resource "azurerm_security_center_contact" "security_center" {
  email               = local.global_variables.security_center_contact
  alert_notifications = false
  alerts_to_admins    = false
}

Expected Behavior

The resource should create the security center contact for the given subscription, then save the state of the resource.

Actual Behavior

When first running, the output of terraform is the following:

Error: Error creating Security Center Contact: security.ContactsClient#Create: Failure responding to request: StatusCode=201 -- Original Error: autorest/azure: Service returned an error. Status=201 Code="Unknown" Message="Unknown service error" Details=[{"etag":"\"ac01bcf3-0000-0d00-0000-5f74442f0000\"","id":"/subscriptions/<subscription id>/providers/Microsoft.Security/securityContact/default1","location":"West Europe","name":"default1","properties":{"alertNotifications":"Off","alertsToAdmins":"Off","email":"[email protected]","phone":""},"type":"Microsoft.Security/securityContact"}]

However the security center contact is created. The problem is that because the state isn't saved, terraform then on the next run attempts to create it again, and receives the standard 'resource already exists' error:

Error: A resource with the ID "/subscriptions/<subscription id>/providers/Microsoft.Security/securityContact/default1" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_security_center_contact" for more information.

Steps to Reproduce

1. Run an apply on a security center contact resources
2. Observe the error message
3. Run another apply

[beandrad]

Duplicate of #8317.

[gettek]

Not a duplicate, this is a separate issue, needs importing into state!

[arbrightmore]

I am experiencing the same issue with the security center contact resource deployment. Removing the tf resource gets rid of the error as expected, however on redeploy the same thing happens:

Error: A resource with the ID "/subscriptions/<subscription id>/providers/Microsoft.Security/securityContact/default1" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_security_center_contact" for more information.

However this also happens with the security center workspace resource:

"/subscriptions/****/providers/Microsoft.Security/workspaceSettings/default" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_security_center_workspace" for more information

This is using:
azurerm provider version 2.34
Terraform version 0.13.3

Issue #8317 is a separate bug to this, not a duplicate

Steps to Reproduce

Run an apply on a security center contact & security center workspace resources
Run another apply
Observe the error message

[tombuildsstuff]

hi @max-mayrhofer @gettek @arbrightmore

As of version 2.0 of the Azure Provider, we require that any existing resources be imported into the state - rather than silently 'upserting' them as we did in 1.x releases - which is why this error message is being returned on a re-run.

Unfortunately the Azure API uses the Provisioning State of "Failed" for multiple instances where this is working just fine (for example, should a Virtual Machine take too long to boot, it's "Failed" but continues working just fine) - as such Terraform is unable to determine every possible failure condition for every API, and instead leans on the operator to determine if this is safe to import the resource and continue, or requires recreation when an error occurs. Whilst it's unfortunate that the Azure API differs in it's behaviour here, at this point in time this behaviour is expected, and is consistent across all resources - existing (working) resources can be imported into the state using terraform import.

Since this behaviour is expected due to "Failed" not necessarily meaning "Failed" - I'm going to close this issue for the moment, but in the case of this specific issue, as @beandrad has mentioned the breaking API change was fixed in #8317. As such this should be fixed for new resources - but existing resources may need to be imported into the state using terraform import to work around the breaking API change here.

Thanks!

[hashibot[bot]]

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!