Incremental deployment fails when destination environment available resource levels are low
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 21m
- Merged PRs (30d)
- 79
Description
**Bicep version**
Bicep CLI version 0.4.1318 (ee0d808f35)
Azure CLI 2.34.1
**Describe the bug**
US West2 is currently under resource restrictions (for net-new and scaling deployments). We have a bicep template that deploys to existing resources in this environment which is currently failing deployment validation even though no new resources are being deployed (or in some cases, no net changes exist). This appears to only effect consumption-based app service plans (Dynamic/Y1), as our other app service plans successfully 'match up' with the existing resources.
The error is:
`ERROR: {"status":"Failed","error":{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.","details":[{"code":"Conflict","message":"{\r\n \"status\": \"Failed\",\r\n \"error\": {\r\n \"code\": \"ResourceDeploymentFailure\",\r\n \"message\": \"The resource operation completed with terminal provisioning state 'Failed'.\",\r\n \"details\": [\r\n {\r\n \"code\": \"DeploymentFailed\",\r\n \"message\": \"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.\",\r\n \"details\": [\r\n {\r\n \"code\": \"Unauthorized\",\r\n \"message\": \"{\\r\\n \\\"Code\\\": \\\"Unauthorized\\\",\\r\\n \\\"Message\\\": \\\"This region has quota of 0 instances for your subscription. Try selecting different region or SKU.\\\",\\r\\n \\\"Target\\\": null,\\r\\n \\\"Details\\\": [\\r\\n {\\r\\n \\\"Message\\\": \\\"This region has quota of 0 instances for your subscription. Try selecting different region or SKU.\\\"\\r\\n },\\r\\n {\\r\\n \\\"Code\\\": \\\"Unauthorized\\\"\\r\\n },\\r\\n {\\r\\n \\\"ErrorEntity\\\": {\\r\\n \\\"ExtendedCode\\\": \\\"52039\\\",\\r\\n \\\"MessageTemplate\\\": \\\"{0}. Try selecting different region or SKU.\\\",\\r\\n \\\"Parameters\\\": [\\r\\n \\\"This region has quota of 0 instances for your subscription\\\"\\r\\n ],\\r\\n \\\"Code\\\": \\\"Unauthorized\\\",\\r\\n \\\"Message\\\": \\\"This region has quota of 0 instances for your subscription. Try selecting different region or SKU.\\\"\\r\\n }\\r\\n }\\r\\n ],\\r\\n \\\"Innererror\\\": null\\r\\n}\"\r\n }\r\n ]\r\n }\r\n ]\r\n }\r\n}"}]}}
`
**To Reproduce**
- Have an existing consumption based app service plan in US West2 (or any other similarly constrained Azure environment)
- Create a bicep template which deploys that same service plan
- Run `az deployment group create ...` referencing the bicep template
**Additional context**
The workaround is to reference the consumption app service plan using the 'existing' keyword, which bypasses the validation that is failing. This does not, however, cause the service plan to be deployed when it is necessary (i.e. standing up a new environment), and is not conducive to CI/CD integration where we need not worry about whether or not the environment is already in the desired state.
Azure developer support believes that our use case requires the use of the 'existing' keyword (which it does not), so I'm bringing this over here in the hopes that someone on this team can point me to the appropriate team/repo (maybe it belongs in the Azure CLI repo?). I'm not sure which team is responsible for managing the 'runtime' aspect of the deployments based on Bicep templates, as this runtime seems to be failing validation inappropriately.
Contributor guide
Research direction
Start by reproducing the failure with an existing consumption-based App Service plan in a constrained region and `az deployment group create ...` using the reported template shape. Compare deployments that use the `existing` keyword with those that do not, then determine whether the failing validation is in Bicep-generated deployment behavior or the Azure deployment service. Done means the responsible component and a supported path for validating unchanged existing plans are identified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100