Deployment failure inner error not shown in many instances
See original GitHub issueAz CLI 2.0.2.
Run the following command:
az vm create -g JMP-AZ10-RHT --name bb-custom-vm100 --image rhel-custom-71 --admin-username azureuser --no-wait
Got this error:
The template deployment ‘vm_deploy_QcfOZ81VGBVOYQxXRfI9GjQJxtSBW8WY’ is not valid according to the validation procedure. The tracking id is ‘c82d598c-50c2-442b-8d0b-43c11da1479e’. See inner errors for details. Please see https://aka.ms/arm-deploy for usage details.
This error is non-actionable. The inner error, however, clearly indicates what failed in the validation:
"statusMessage": "{\"error\":{\"code\":\"InvalidTemplateDeployment\",\"message\":\"The template deployment 'vm_deploy_QcfOZ81VGBVOYQxXRfI9GjQJxtSBW8WY' is not valid according to the validation procedure. The tracking id is 'c82d598c-50c2-442b-8d0b-43c11da1479e'. See inner errors for details. Please see https://aka.ms/arm-deploy for usage details.\",\"details\":[{\"code\":\"QuotaExceeded\",\"message\":\"Operation results in exceeding quota limits of Core. Maximum allowed: 100, Current in use: 100, Additional requested: 1.\"}]}}"
},
Copy-pasting tail end of the above message:
Operation results in exceeding quota limits of Core. Maximum allowed: 100, Current in use: 100, Additional requested: 1.
My request here is to pull this inner information and provide it in the CLI error message as it saves me loading the portal, going to activity log and finding it there.
If there is already a way to get this in some detailed log of the az CLI execution, the error message should be expanded to provide the info on how to find it (e.g. azure CLI 1.0 was referring to azure.error.detailed file or something like that).
Issue Analytics
- State:
- Created 6 years ago
- Comments:13 (6 by maintainers)
Top GitHub Comments
@dctucker you are using a version of the CLI that is over 6 months old. I’d recommend you try it on a newer version and if the errors are still too vague, open a new issue.
I propose re-opening this issue, as the error messaging is still pretty vague, even without specifying
--no-wait
. We are using version 2.0.29 on Debian.