[Feature Suggestion] Deployment Parameters: Allow unused paramaters in deployment

[mfeyx]

Is your feature request related to a problem? Please describe

I want to deploy resources based on a params.json file. If unused parameters are present the deployment currently fails:

InvalidTemplate - Deployment template validation failed: 'The template parameters 'rg_tags' in the parameters file are not valid; they are not present in the original template and can therefore not be provided at deployment time. The only supported parameters for this template are 'name, tags'.

main.bicep

param name string
param tags object

resource storage 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: name
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_ZRS'
  }
  properties: {
    accessTier: 'Cool'
  }

  tags: tags
}

params.json

{
  "id": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "title": "Parameters",
  "description": "An Azure deployment parameter file",
  "type": "object",
  "parameters": {
    "name": {
      "value": "mystoragename"
    },
    "rg_tags": {
      "value": {
        "businessowner": "tba",
        "project": "tba"
      }
    },
    "tags": {
      "value": {
        "application": "XYZ",
        "version": "0.0.1"
      }
    }
  }
}

Describe the solution you'd like

Basically, I want to deploy resources without having to delete parameters in the parameters file. I want to be able to define parameters even though they might not be used in a deployment. When I deploy a resource group, for instance, I will use my rg_tags values from the parameters, but not the normal tags that might be used in other deployments.

Edit: Sorry, I forget the command I use.

az deployment group what-if --resource-group "MY_RESOURCE_GROUP" -f "main.bicep" --parameters "params.json"

Hope this is the right place for the suggestion.

Kind regards :)

[wsmelton]

Duplicate #5742

[mfeyx]

hi @wsmelton,

I found that issue you mention above (#5742), but I thought it is not the same request as mine, even though it is similar. My suggestion is to not throw an error, like InvalidTemplate, if a parameter is unused. There is no conditional logic behind my request. I hope I could make myself clear :)

Kind regards

[wsmelton]

Oh, the param file itself. I would believe that has to be addressed upstream since validating the param to the template is done at the deployment PUT endpoint.

[mfeyx]

Oh, the param file itself. I would believe that has to be addressed upstream since validating the param to the template is done at the deployment PUT endpoint.

Thanks for your quick response @wsmelton! When you say "upstream" you mean I have to file this request somewhere else?

Kind regards

[mfeyx]

Opened the issue elsewhere, so I will close it here.

[jikuja]

Would it be possible to re-open this?

#5742 is not really a dupe of this at all.

Also this feature request should be handled on https://github.com/Azure/bicep/issues/7301 and tickets describing .bicepparams usage.

[alex-frankel]

@jikuja agreed this is not a dupe and agreed we could (not necessarily should) feasibly address this with .bicepparams support. I will re-open.

[alex-frankel]

Curious to understand what the potential negative implications would be for starting to allow this. We could emit a warning in the language service and as part of emitting ARM parameters and ARM template. When would a warning not be sufficient? cc @bmoore-mstf who may know more about this.

[jikuja]

One option might be adding option for tooling to

• ignore
• warn
• error (current behaviour) if unused parameters are being passed.

---

What would be correct level to implement this check?

• Tooling only or tooling and API? (See next section for more info)

---

API: How does PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Resources/deployments/{deploymentName}?api-version=2021-04-01 and others handle deployments if properties.parameters or properties.parametersLink has unused parameters.

[jikuja]

BCP259(1) is now making more client-side assumptions about failing when unused paramters are being passed.

(1) bicep build-params => $"The parameter "{identifier}" is assigned in the params file without being declared in the Bicep file."

[darren-mair]

+1 for this, would also help with Yaml templates for multiple deployments using same template

[r0b3rtk]

+1 for this issue. Our use case is that we want to split one large Bicep file that is describing all resources of a spoke into multiple smaller bicep files. This spoke is deployed multiple times (e.g. one for Dev environment, one for Test and so on), so having a single parameter file per environment would be ideal.

[alex-frankel]

@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like

[Rasmus715]

+1

[Rasmus715]

@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like

Please look at the OP issue. Imagine a second bicep file that'll use both "rg_tags", "tags" and "name" parameters. That's exactly the case that you're looking for and what I'm facing right now.

[mfeyx]

In the meantime, I wrote a little helper script that can be found here: https://github.com/Azure/azure-cli/issues/21149#issuecomment-1256639995

[darren-mair]

@darren-mair / @r0b3rtk - can you provide example bicepparam file and 2+ bicep files that demonstrate this? I am having trouble visualizing what this structure would look like.

@alex-frankel Apologies for delay, i'll explain as best i can. We use YAML templates with CLI task and it uses parameters so we can use different bicep files with the same template as below.

Problem being we can only do this for bicep files that expect the same parameter inputs from Yaml, otherwise we have to create another template. Say for example 1 bicep file is expecting DNSSubscriptionID, but the second isn't. We then get error saying unexpected parameter.

if we could have the ability for bicep to ignore any parameters passed that are not declared, it would mean we could use the same YAML template file with all the Param overrides for all bicep main files. This would be unbelievable good.

[ryancolley]

@alex-frankel Is this something that is being worked on by chance?

We have scenario where the vast majority of our bicep modules are using a central bicep module file for some key parameters etc, and having the ability to assign parameters up the chain using the .bicepparam file would be extremely useful to us.

Or perhaps there is a way to suppress error BCP259?

kind regards

[Saulopv]

+1

[GregorieCalderon]

+1 This should be allowed. We use 1 BICEP params file for multiple deployments but due to this 'warning', we are unable to complete this the way we'd like. Its been 2 years (going on 3), i wonder if anyone cares about this issue.

@alex-frankel any update?

[autinerd]

Especially with #13900 the feature is very interesting, for example when I define a base bicepparam with some constants which don't apply to all resource types.

[wsmelton]

For the number of folks that have posted only +1 please stop doing that on repositories, it is unnecessary noise. If you are doing it to "follow" the issue, hit the subscribe button to accomplish the same thing.

Azure team prioritizes issues based on the votes, not the number of posts in an issue. Everyone (please) 👍🏻 the initial post for it to get prioritized.