PSArm icon indicating copy to clipboard operation
PSArm copied to clipboard

Add a way to handle API versions for resources

Open rjmholt opened this issue 4 years ago • 3 comments

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.

rjmholt avatar May 06 '20 04:05 rjmholt

EDIT: Moved this comment to #22

rjmholt avatar May 14 '20 20:05 rjmholt

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:

  • Store keyword schemas in a format that includes the resource namespace, name and API version. How exactly depends on whether each resource API version changes independently, or if the whole namespace keeps the same version (my suspicion is the former, which means we need to change the way we store schemas currently).
    • One possibility might be a directory structure, where namespaces are directories. Resources seem to be sub-namespaceable though, so we would need to work out how that works.
  • When a resource has an API version set, we look up the corresponding schema file and pull that
  • When a resource has no API version set we use some way to assume a default version
  • Complete on API versions based on resource type

rjmholt avatar May 14 '20 20:05 rjmholt

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"

kilasuit avatar Jul 14 '20 12:07 kilasuit