Coming soon - Get a detailed view of why an account is flagged as spam!
view details

This post has been de-listed

It is no longer included in search results and normal feeds (front page, hot posts, subreddit posts, etc). It remains visible only via the author's post history.

6
Lack of Idempotency in creation of MySQL Read Replica via ARM template
Post Flair (click to view more posts with a particular flair)
Post Body

This is a bit of a quasi-rant/asking for help with an issue:

I am trying to create a Read Replica for a MySQL server using an ARM template. I am running into an issue when applying the same template again and getting a "SeverNameAlreadyExists" error. To reproduce the error I have this:

  1. Template A creates a MySQL server and a sub-resource of a read replica dependent on that server
    Results: This works the first time, every time.
  2. Run Template A again with no changes.
    Results: Replica Creation fails on "ServerNameAlreadyExists"
  3. Template B creates just a MySQL server
    Results: A MySQL server is created
  4. Run Template B again.
    Results: No changes to the MySQL server from the original run in (3). This can be repeated as much as I want.
  5. Template C creates just a MySQL server read replica using an already existing server as its parent
    Results: Read Replica for the parent server is created normally
  6. Run Template C again.
    Results: I receive the error "ServerNameAlreadyExists"
  7. Modify Template C so that createMode is Default instead of of Replica
    Results: Applies successfully. No apparent changes to the Read Replica / Parent relationship. This can be run multiple times.

Per MS Support this is expected behavior.

While I am new to ARM, I have used other applications that are idempotent* (Terraform, Ansible) and this to me seems to violate the following statement in Azure's documentation (emphasis mine):

  • Repeatable results: Repeatedly deploy your infrastructure throughout the development lifecycle and have confidence your resources are deployed in a consistent manner. Templates are idempotent, which means you can deploy the same template many times and get the same resource types in the same state. You can develop one template that represents the desired state, rather than developing lots of separate templates to represent updates.

Right now, in order to avoid this error, we have to consider the state of the deployment and make changes to the parameters at in step (7). This feels fairly cludgey to me.

Has anyone else experienced this before? Is there a better work around?

* I know TF and Ansible have some quirks sometimes that don't make them completely idempotent.

Author
Account Strength
90%
Account Age
5 years
Verified Email
Yes
Verified Flair
No
Total Karma
776
Link Karma
27
Comment Karma
749
Profile updated: 3 days ago
Posts updated: 2 weeks ago

Subreddit

Post Details

We try to extract some basic information from the post title. This is not always successful or accurate, please use your best judgement and compare these values to the post title and body for confirmation.
Posted
3 years ago