Please add stronger typing to parameters, a bit like CreateUiDefinition

[peter-bertok]

(I know this has been discussed in various forums before, but from what I've read all of the various ARM-related teams just point fingers at each other or make suggestions that aren't practical for end-users.)

A key feature of PowerShell is that parameters are strongly typed. This is also the hallmark feature of most programming languages as well. However, there appears to be a insistence in the various ARM language tooling to make all inputs plain strings. This makes restricting inputs to valid values much harder for end-users and is a maintenance nightmare.

I've seen templates in the wild hard-code the full list of Azure regions... which goes out of date every 6 months or so when a new PoP goes live.

I've seen templates hard-code VM SKUs, which prevents them using perfectly valid AMD EPYC models for no good reason. (I've even seen Azure staff do this in C# code, breaking things like the SQL Virtual Machine resource on AMD, but that's another story.)

It would be enormously beneficial to provide strong input typing and filtering similar to what CreateUiDefinition does.

E.g.: "location" shouldn't accept arbitrary gibberish, but should filter down to the intersection of valid Azure location strings and locations where the template can be validly deployed. This should be reflected in the Portal Custom Template GUI, and the PowerShell command-line tab complete, and the "az" tool, and the VS Code parameter validator, and so on.

CreateUiDefinition itself isn't the same thing. It doesn't work on the command line, for one! It won't work between Bicep modules, as a second issue. It's absurdly complex and difficult to author. It requires many extra steps.

What I would like to see is:

• ARM should include an extra parameter metadata attribute called "strongtype", much like Blueprints allow now.
• Bicep should make it trivial to strongly type a parameter. E.g.: Instead of just string/bool/int/object, also allow resource type names in the same spot.
• Either the ARM language or the ARM tooling should include similar processing that CreateUiDefinition does. E.g.: The ability to compute the list of required resource providers to enable location filtering. Ideally this should be dynamic to support conditionals better...
• Bicep should integrate with the above. E.g.: automatically generate the resource provider list.
• Both ARM and Bicep should have features to retrieve properties of complex parameters. E.g.: most SKUs are actually about 3-4 separate properties, but the param and the GUI should prompt the user for only one thing.

Some ideas of how the syntax may look:

param Subnet 'Microsoft.Network/virtualNetworks/subnets'

param Location location {
  require: [
    'Microsoft.Network'
    'Microsoft.Compute'
    'Microsoft.SQL'
  ]
}

// It's as if the resource was looked up using "reference()"
output SubnetId string = Subnet.id
output SubnetName string = Subnet.Name

[alex-frankel]

Hi Peter,

First off, we are very open to expanding the available types that are available to set on a parameter or output, and the bicep-system is being built to have functionality like that added, we are just not there yet. There's definitely a growing need to pass around resources between modules so I expect us to have something available like you are describing in the first line of your code sample (param subnet ...) and the outputs at the end of your sample should work more or less as you've described:

We also should be able to allow you to query information about a type, i.e.

var vmSkus  = virtualMachines.skus

I'm not following the second block of code. What is this enabling/restricting?

param Location location {
  require: [
    'Microsoft.Network'
    'Microsoft.Compute'
    'Microsoft.SQL'
  ]
}

I will say that sometimes we "point fingers" to make sure that that right fix happens in the right spot. For example, we may add some functionality to bicep to evaluate more types, but we will also need to make sure the RP teams are producing complete & accurate swagger files to make sure we process those details into the type system correctly.

[peter-bertok]

I'm not following the second block of code. What is this enabling/restricting?

I noticed that CreateUIDefinition allows locations to be restricted based on the resource providers available at that location, which is neat. Similarly, it would be ever so useful to be able to request SKUs based on requirements. E.g.: VM SKUs filtered to include a minimum amount of memory, Accelerated Networking, a certain number of NICs, etc...

[johnnyreilly]

This is not an answer to this but a related issue: #3723

[brwilkinson]

Closing this discussion since there are several other related open issues e.g. #622 or #3723

[brwilkinson]

more information on the current status of this in #622

Will leave open for now.