2.3.0: Breaking changes to template deployments when using --template-uri

[noelbundick]

Describe the bug

Starting with azure-cli 2.3.0, the default behavior has been updated to process extended JSON syntax.

Previously, a template deployed with --template-uri would be executed with the templateLink property set. At runtime, [deployment().properties.templateLink.uri] would be accessible

With the new behavior, the CLI will download the template from the remote host, preprocess it, then PUT a deployment with template set. At runtime, [deployment().properties.templateLink.uri] is not accessible.

This appears to be an undocumented breaking change and causes my templates to fail

The following test recording was last run in Dec 2019. I believe if re-run today, this would demonstrate different results showing a PUT with the full template rather than the templateUri: https://github.com/Azure/azure-cli/blob/991cb7cc7c9e577d8bec3b78e0316dfb5d39fe10/src/azure-cli/azure/cli/command_modules/resource/tests/latest/recordings/test_group_deployment_thru_uri.yaml

Command Name
az deployment group create

Errors:
Template deploys successfully. [deployment().properties.templateLink] does not exist

To Reproduce:

• az group create -n test1 -l westus2
• az deployment group create -g test1 --template-uri https://gist.githubusercontent.com/noelbundick/2a599b3954c9c4e47754151f138d942a/raw/45e64f07f4c82462ebcb09c6bd083ae01c3e4d3c/azuredeploy.json

Expected Behavior

[deployment().properties.templateLink] is available per the previous behavior and documentation (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-functions-deployment#deployment)

Environment Summary

Linux-4.19.84-microsoft-standard-x86_64-with-debian-buster-sid
Python 3.6.5
Installer: DEB

azure-cli 2.3.0 *
azure-cli-ml 1.0.85

Extensions:
azure-cli-ml 1.0.85
azure-devops 0.16.0

Additional Context

I have a sample zero resource template here that demonstrates the issue: https://gist.github.com/noelbundick/2a599b3954c9c4e47754151f138d942a

Works (2.2.0):

docker run --rm -it -v /home/$USER/.azure:/root/.azure mcr.microsoft.com/azure-cli:2.2.0 bash
az deployment group create -g test1 --template-uri https://gist.githubusercontent.com/noelbundick/2a599b3954c9c4e47754151f138d942a/raw/45e64f07f4c82462ebcb09c6bd083ae01c3e4d3c/azuredeploy.json

Fails (2.3.0):

docker run --rm -it -v /home/$USER/.azure:/root/.azure mcr.microsoft.com/azure-cli:2.3.0 bash
az deployment group create -g test1 --template-uri https://gist.githubusercontent.com/noelbundick/2a599b3954c9c4e47754151f138d942a/raw/45e64f07f4c82462ebcb09c6bd083ae01c3e4d3c/azuredeploy.json

I found these links relevant while investigating

• Large refactor: [ARM] Refactor deployment commands #10751
• Default to use extended JSON by default: [ARM] az deployment create/validate: Use --handle-extended-json-format by default (#12066) #12455
• Retrieving the JSON from the --template-uri:

  azure-cli/src/azure-cli/azure/cli/command_modules/resource/custom.py

  Line 280 in a792aaa

  if template_uri:

• If template and templateLink are both set, blank out the template:

  azure-cli/src/azure-cli/azure/cli/command_modules/resource/custom.py

  Line 373 in a792aaa

  del http_request.data["properties"]["templateLink"]

cc: @alex-frankel

[yonzhan]

add to S169

[ckittel]

Also reported at in #12990. (just cross linking for folks that might be following one but not the other)

[ckittel]

This was in 169. Does this mean that it's going to be delayed? azbb (from p&p team) is broken until this is fixed. Feel free to follow up with me on Teams if there are questions, @yonzhan.

This is also not a feature request, it's a breaking change that's impacting customers.

[yonzhan]

@ckittel Thanks to bring it out. We will plan it in this Sprint with high priority.

[ckittel]

Thank you @yonzhan -- there are becoming more and more reports of this. Basically anyone using az cli to do template uri-based deployments where the templates use the templateLink property are running into this.

[zhoxing-ms]

@noelbundick @ckittel Hi, this is the same problem as #13317, and I have submitted a PR #13344 to fix it~ You can track the progress of the problem through this PR.