Bicep module to support debugSetting feature

[slapointe]

UPDATE: the issue is now only for debugSetting, not complete parity with Microsoft.Resources/deployments

I was helping on an issue yesterday and wanted to turn on debugSetting on a nested deployment (I was using a module) and it hit me.

It is very easy and convenient today to use modules, they translate into Microsoft.Resources/deployments. There is no way to set the properties on a Module like it is possible to with Microsoft.Resources/deployments

Describe the solution you'd like I'd like to be able to control the properties like

    debugSetting: {
      detailLevel: 'string'
    }

I know I could declare a deployment resource in Bicep but I loose the transpile and ease that module provides.

I'd like to be able to declare the following in a module:

module keyVault 'keyvault.bicep' = {
  name: 'keyVaultDeployment'
  properties: {
    debugSetting: {
      detailLevel : 'requestContent, responseContent'
    }
  }
}

[slavizh]

Some options probably should not be provided to avoid confusion and encourage usage of upcoming deployment stacks - mode, onErrorDeployment. I believe also some of the settings could not be used on nested templates.

[alex-frankel]

I don't think we want 1:1 parity. As Stan mentioned, there are some capabilities like onErrorDeployment, mode, and the api version we use that we intentionally do not want to expose.

I could potentially see us exposing the debug setting, but would want to discuss that further.

[slavizh]

to be honest I have never used the debug settings in real life troubleshooting. They could be useful but in a very rare scenarios for troubleshooting.

[slapointe]

Yeah, the need originally was for debugSetting. We could remove the ask for parity here.

[slapointe]

To be fair, and aligned with @slavizh's comment. We can ask if people want this.

If not, I'll continue switching the value in a ARM template that I reference as the module source.

[jikuja]

HUGE +1

Was going to file a bug report for this but checked existing ones first.

---

Use case: I tried to debug why module creating storage account is returning

deployment error message:

{
    "status": "Failed",
    "error": {
        "code": "ResourceDeploymentFailure",
        "message": "The response for resource had empty or invalid content."
    }
}

This error message is not really helpful in this case.

---

After manually deploying module with debugSetting enabled I got following results: deployment error message(same error):

{
    "status": "Failed",
    "error": {
        "code": "ResourceDeploymentFailure",
        "message": "The response for resource had empty or invalid content."
    }
}

and on Get-AzureRmResourceGroupDeploymentOperation => $operation.Properties.Response: (debug response on deploymen operations)

"response": {
        "content": {
          "error": {
            "code": "NetworkAclsValidationFailure",
            "message": "Validation of network acls failure: ResourceGroupNotFound:Resource group 't20221127-network-prod-rg' could not be found.."
          },
          "status": "Failed"
}

In this case deployment failure root cause was instantly found after enabling debuggin for given template.

---

Sadly looks like tooling support to inject debugSetting is really bad:

• Az Powershell: supports
• Az CLI: no support
• ADO tasks: probably not supporting
• Portal: nope

[alex-frankel]

@jikuja -- this looks like a slightly different issue. The second error was caught during preflight validation. It didn't manifest in the more complex deployment because the preflight evaluation has a tendency to short-circuit with a particular usage pattern with modules.

Changing the debug setting would allow you to inspect the details of the request, but won't change the error message itself.

[jikuja]

Changing the debug setting would allow you to inspect the details of the request, but won't change the error message itself.

True. Updated my message.

But does not change the facts that:

1. debug level is not inherited into nested templates
2. response gave answer

This was the erroring deployment result on Portal:

Response was in this case much more better that Status message. I might try this later:

• build to JSON
• inject debuglevel for all nested template
• check if same error and response are present

[alex-frankel]

check if same error and response are present

My assumption is the error will be the same both with and without the debug setting. In the second case, the template didn't pass validation and the RP handles it and gives a helpful error message. In the earlier case, the validation error was missed (not related to debug settings), which apparently results in an Internal Server Error (which is a bug in the resource provider service).