Open rjmholt opened 4 years ago
EDIT: Moved this comment to #22
On the API version front, these seem to just be versions of the API surface. I was worried they might be subject to some kind of combination/composition logic (since the schemas frame them that way), but I don't think they are.
Instead, my proposal is to:
We do this in current ARM Templates via a variable as per the below in our controller template which is then passed down to any other child templates that we use. This to me seems like a sensible practice
"variables": {
"ApiVersion": {
"Network": "2018-02-01",
"VM": "2018-04-01",
"Default": "2018-05-01"
}
}
Ideally the implementation should allow the author to set this in a PowerShell variable & just default to a set API version if it's not provided (Ideally latest non-preview version) but override when set in this manner, though perhaps needs to use the full resource type as the property name
$ApiVersion = [PSCustomObject]@{
"Microsoft.Network/virtualNetworks" = "2018-02-01",
"Microsoft.Compute/virtualMachines" = "2018-04-01",
"Default"= "2018-05-01"
}
Or better still something along these lines
$ApiVersion = [AzureResourceManagerAPIVersionColllection]::new()
$APIVersion.virtualNetworks = "2018-02-01",
$APIVersion.virtualMachines= "2018-04-01",
$APIVersion."Microsoft.Compute" = "2018-03-01"
$APIVersion.Default = "2018-05-01"
Currently we just treat the API version parameters as settable data, even though these fields hugely affect the shape of APIs.
We need a mechanism to sort APIs by version and allow cataloguing and completing on API versions for resources, as well as having a reasonable scheme for setting the template-wide API version.