Share via

Azure Postgres read-only replica creation via ARM templates is not idempotent

Petru Dumuta 11 Reputation points
2020-09-04T12:50:40.69+00:00

Hi,

This is somehow related to the issue reported here enabling-replication-via-arm-template-not-idempotent

I'm creating an Azure Postgres instance and a read-only replica for that instance using the ARM template attached to this question.

When I run the template for the first time everything works great -- both the DB and the replica instance are created successfully. However, when I try to run it a second time I get the following error: 

Deployment failed. Correlation ID: 391e2a5c-7b6c-4e9e-800b-f8640ff6fa68. {
  "status": "Failed",
  "error": {
    "code": "ResourceDeploymentFailure",
    "message": "The resource operation completed with terminal provisioning state 'Failed'.",
    "details": [
      {
        "code": "ServerNameAlreadyExists",
        "message": "Specified server name '{0}' is already used. Please use a different name and try again."
      }
    ]
  }
}

This is not what I would expect -- I think that the expected behaviour should be for nothing to happen (as long as no configurations were changed) and not for the run to fail.

Am I doing something wrong or this is a real issue/limitation with creating DB replicas using ARM templates?

Azure Database for PostgreSQL

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Mike Ubezzi 2,776 Reputation points
    2020-09-04T22:31:22.72+00:00

    Hi @Petru Dumuta - The current means for validating ARM Templates is through the use of VSCode with the ARM Template extension: Create Azure Resource Manager templates with Visual Studio Code (Link)

    This will give you the ability to at least validate the template and the second part of the same document discusses the creation of a parameters file.

    Additionally, there is a means to crate a template spec: Create and deploy template spec (Preview) and the template spec can include a parameter values: Deploy a template spec.

    With a Template Spec, you reference the resource ID of the template spec you desire to deploy. This along with working with ARM in VSCode and the creation of a parameters file, you can introduce some logic to handle and mitigate this. This Stack Overflow thread has some good information on the subject, with regard to running a template multiple times: Azure - do not allow Arm template to modify existing resources where the take away is that ARM by itself has no means to handle error or retry logic at this time, and you need to leverage a scripting and parameters file to dynamically handle the idempotent aspect that you are seeking.

    You might be better converting your templates to Powershell scripts (or REST API calls) that way you can check the state prior to creating / amending details.

    This means you need to dynamically handle the deployment mode (Azure Resource Manager deployment modes) to ensure the process understands that the update is either incremental or complete.

    When deploying your resources, you specify that the deployment is either an incremental update or a complete update. The difference between these two modes is how Resource Manager handles existing resources in the resource group that aren't in the template.

    For Reference:

    0 comments