azd provision --no-prompt does not see detect deleted SQL Server

[ryanheath]

azd provision --no-prompt does not detect a deleted Azure SQL Server.
Other components are being recreated/deployed, but not Azure SQL Server.

What are we doing wrong?

Note, we are using azd config set alpha.aca.persistDomains on
maybe it is related?

Output of azd (latest version is installed via https://aka.ms/install-azd.sh)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Analyzing Aspire Application (this might take a moment...)
Downloading Bicep
  (✓) Done: Downloading Bicep
Initialize bicep provider
Retrieving subscriptions...
Reading subscription and location from environment...
Subscription: ***
Location: West Europe

Creating a deployment plan
Comparing deployment state
  (-) Skipped: Didn't find new changes.

SUCCESS: There are no changes to provision for your application.

[rajeshkamal5050]

@vhvb1989 any thoughts on why this could happen?

[vhvb1989]

@ryanheath , can you describe how the SQL Server was deleted?

[ryanheath]

Via the Azure Portal | Delete Button on the resource | Skipped the feedback | confirmed the name | delete SQL server resource.

[ellismg]

Hi @ryanheath,

We have an optimization in provision that tries to skip the deployment if it thinks there have been no changes. It does this by comparing the current deployment template (in this case generated behind the scenes for you by Aspire) with the last one that was deployed. If there are the same, it skips submitting the deployment. It doesn't consider changes made outside of the template (e.g. if you manually change a property or delete a resource via the portal or with the az CLI).

You can pass --no-state to provision to force azd to tell ARM to do the deployment (and ARM will notice the SQL server has been deleted). I think if you run azd provison --no-state --no-prompt it should force a deployment and the SQL Server will be re-created.

The output here was trying to get the point across (with the skipped line) :

Creating a deployment plan
Comparing deployment state
  (-) Skipped: Didn't find new changes.

Perhaps we should update the copy to be something like this:

Creating a deployment plan
Comparing deployment state
  (-) Skipped: Didn't find new changes (re-run with `--no-state` to force a deployment).

Do you think if there had been text like that it might have been a little more clear about what was going on and helped you solve the issue yourself?

[vhvb1989]

@ryanheath , that's expected by design.
Azd's provision cache is not aware of external changes. You can use azd provision --no-state to make azd to ignore cache and run your resources's deployment.

Azd's cache is based on changed to the AppHost (your program) and the last deployment to Azure.

[ryanheath]

But will it redeploy existing resources too?
I do not want to overwrite/redeploy anything that does not need to.

[ellismg]

But will it redeploy existing resources too?
I do not want to overwrite/redeploy anything that does not need to.

@ryanheath It will not overwrite/redeploy anything that it does not need to. If you have changed properties for existing resources manually in the portal it will change them back to their previous values, but if there are no changes the ARM deployment engine is smart enough to make no changes (the reason we did additional work in azd to skip these "no-op" deployments is they take a bit longer and we wanted a faster user experience).

Note in Aspire the provision command does not have any impact on the individual container apps themselves, so if you've changed properties of the container apps, they will not be reset.

[ryanheath]

Unfortunately we had already deleted the whole resource group ...
But deploying with --no-state seems to do what we want anyway.
In our case a redeployment is not significant longer with --no-state than without.

[ellismg]

In our case a redeployment is not significant longer with --no-state than without.

Thanks, that's good information for us to have. We'll look into if this optimization is still paying for itself.

Glad to hear you got things working, FWIW, it is "safe" to always pass --no-state if you'd like - it just means provision may take a bit longer in the nothing to do case.