Reploying the same resources, even when no change?

[scheung38]

Bicep version
run bicep --version via the Bicep CLI, az bicep version via the AZ CLI or via VS code by navigating to the extensions tab and searching for Bicep

az bicep version
Bicep CLI version 0.6.18 (46dd19e)

Describe the bug
A clear and concise description of what the bug is vs what you expected to happen

Why is bicep not skipping deployment when nothing changed in subsequent runs?

main.bicep:

resource storageaccount 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: AZURE_STORAGE_ACCOUNT_ID
  location: uksouth
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  } 
}

This took close to 19 mins to deploy and without further changes same the same amount of time each time ? Where is the preflight to check nothing changed? If preflight in there then it should not have reployed the same config next time az deployment group create is executed?

To Reproduce
Steps to reproduce the behavior:
az deployment group create --resource-group $MY_GROUP --template-file bicep/main.bicep --mode Complete

Additional context
Add any other context about the problem here.
Is this related to already provisioned resources in AKS cluster, but excluded from current deploy?

Mac OSX 12.4

[alex-frankel]

ARM Template (and Bicep) deployments have no representation of state to know if a resource is already deployed or not. It naively sends the PUT request to the RP to create/update the resource and it is up to relevant resource provider to be efficient with a no-op like that. There is no guarantee they are being efficient. We would recommend opening up a support ticket for this particular issue.

[brwilkinson]

To add to this it is extremely unusual for a storage account deployment to take more than a few minutes.

Either the first time or any time later in the lifecycle.

Perhaps there are some additional configurations on the storage account? I would recommend to take a look at the Azure Activity log on the resource group, you will likely see errors, perhaps relating to private link or DNS etc..

Or jump straight to the support ticket as Alex mentioned to track down the issue, if you haven't done so already.

Either way please keep us updated on your progress.

[brwilkinson]

Hi @scheung38 please keep us posted on your progress.

I would also recommend deploying a brand new storage account, multiples of times to test the experience. The deployment should take under a minute.

[jolindroth]

Coming from AWS, the behavior is surprising and means you have to think twice on how you setup your cicd pipelines. It makes it unnatural to manage your code and infra in the same repository and pipeline, which I prefer in many cases.

One way to deal with this is to make a check for changes to the bicep files in the pipeline before deploying the infrastructure.

[brwilkinson]

@jolindroth

Which behavior are you referring?

There is nothing special that you need to do or test for.

Bicep templates are idempotent and you can redeploy them as many times as you like, only changes in your template will be applied.

[jolindroth]

@brwilkinson

I'm referring to the preflight/no-op check which is discussed above. I would expect the behavior be that azure skips, rather than redeploy resources when a redeploy will not result in any resources being modified.

This is important in cases where the application code deployment is dependent on the successful execution of the IaC job. In a setup like that, application code may be deployed much more often than infrastructure changes and so waiting for an unnecessary redeploy will slow down the application code deployment.

[brwilkinson]

@jolindroth

I see.. Yes it redeploys, however this thread is misleading, since if resources exist, deployments can take just a few seconds.

[brwilkinson]

@jolindroth

Just to add ... Azure is an extensible model that uses a standard method for management. This method is the Azure Resource Manager (ARM).

The extensibility or Resource Providers include Core and Azure Native RP's like network, storage and compute and many third party RPs.

The way each RP manages what happens inside of the deployment is up to that RP and ARM is just the agent responsible for running the deployments.

Example. Lets say I have a Virtual Machine and that virtual Machine has extensions. The extensions could also be first party or third party.

So if you deploy the VM with the custom script extension, then if you redeploy a second time, the custom script extension detects no properties changes on the deployment and skips execution. Now if you have a third party extension, the way that extension detects if it should re-apply is up to the Code used inside of the Extensions.

So we have: Azure Resource Manager (ARM) --> Microsoft.Compute (Resource Provider) --> Third party Extension.

So to summarize, yes your milage may vary on what happens in the Third Party Extension and that is beyond control from ARM.

Generally if you redeploy a PaaS resource provider, such as AKS or a Storage Account, a redeploy should take seconds, so long as no properties have changed. If you redeploy a Virtual machine (IaaS), it has to re-run/validate the extensions, then it's up to the extensions what happens and how long it takes.

if you see deployments taking more than a few minutes on a redeploy, such as why this thread was opened saying a storage account is taking 15 minutes, ... in that case you should definitely open a support ticket against that resource for investigation.

If you have other specific questions on specific resource provider types and expected outcomes, please feel free to share more info.

[jachin84]

I have been with Azure since before Azure Resource Manager. For me, ARM has always been a bit flaky when reapplying a deployment. The promise, at a high-level, is that you can reapply a template with confidence. Have a look at the docs, template are supposed to be idempotent: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/overview.

In my experience, this has never really been true and it seems to be getting worse. A more accurate description of ARM/Bicep is that you might get repeatable results depending on how a given resource provider has implemented their integration with ARM. As an end user there is really know way to know which resource providers do a good or bad job of that until you try it out. In my most recent support case it was suggested that Terraform and direct API manipulation would be the best course forward...