Synapse Managed Private Endpoint deployment doesn't wait for provisioning to be completed

[jjgriff93]

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 v0.13.5
AzureRM v2.55.0

Affected Resource(s)

• azurerm__synapse_managed_private_endpoint

Terraform Configuration Files

# Create a managed private endpoint so Synapse can talk to Cosmos
resource "azurerm_synapse_managed_private_endpoint" "cosmos_region1" {
  name                 = "cosmos_region1_endpoint"
  synapse_workspace_id = azurerm_synapse_workspace.synapse_workspace.id
  target_resource_id   = var.cosmos_account_id
  subresource_name     = "Analytical"
  depends_on           = [azurerm_synapse_firewall_rule.allow_all]
}

Expected Behaviour

On running the above configuration, a Managed Private Endpoint is both requested from the management plane of Azure Synapse successfully, and then the provisioning status API on the Synapse management plane is polled until the status updates from provisioning to succeeded. Terraform will then proceed with dependent items or fail the deployment if Synapse fails to deploy the endpoint.

Actual Behaviour

Currently, this configuration successfully requests a Managed Private Endpoint from the Synapse management plane; however once it's done this it simply completes, without waiting to see if the MPE has actually been provisioned.

Subsequently, any steps that are dependent on the Managed Private Endpoint, such as the below approval step of the MPE within Cosmos DB:

# Once the Synapse Managed Endpoint request has been created, approve it within Cosmos
resource "null_resource" "approve_cosmos_pe" {
  triggers = {
    run_when_cosmos_pe_created = azurerm_synapse_managed_private_endpoint.cosmos_region1.id
  }
  provisioner "local-exec" {
    command = <<-EOT
      az cosmosdb private-endpoint-connection approve \
        --account-name ${var.cosmos_account_name} \
        --name ${azurerm_synapse_managed_private_endpoint.cosmos_region1.name} \
        --resource-group ${var.resource_group_name} \
        --description "Approved automatically by Terraform."
    EOT
  }
  # Currently TF synapse pendpoint resource completes when its created, NOT provisioned, so we must manually wait for it
  depends_on = [azurerm_private_endpoint.synapse_private_endpoint]
}

Will likely fail, as the MPE can take several minutes to deploy and Terraform will have moved on to these steps without the provisioning actually having been completed.

Steps to Reproduce

1. Create a Synapse workspace with Managed Virtual Network enabled and a Cosmos DB account with virtual networking enabled
2. Add a step to create the Synapse Managed Private Endpoint to Cosmos (you can do this to the Sql sub-resource if the Cosmos DB account in question does not have Analytical enabled, as the problem occurs in both instances
3. Add the null_resource Azure CLI approval step for the MPE as described in the prev section with a depends_on on the Managed Private Endpoint step
4. terraform apply

You will find that the Managed Private Endpoint deployment will complete within a few seconds, then when the Cosmos Az CLI approval step tries to execute afterwards, you will get a 404 MPE not found (as it has not yet been provisioned). You can then confirm this (if you're quick enough) by heading to your Synapse portal, and looking in the Private Endpoints section of the settings menu, and it will still be in a Provisioning state.

• #0000

[github-actions]

This functionality has been released in v2.83.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!