Feature: Resource Template Deployment CRD or generic resource

[old-guy-coder]

Request a feature to add a CRD in ASO to support applying an ARM fragment using a kubernetes resource, this could be similar to how Terraform support this using the azurerm_resource_group_template_deployment resource.

I could see use cases where this would be useful to allow the support of Day 0 resources that are supported in ARM but not currently implemented in ASO as a temporary measure until they do become available.

The resource might look something like this:

apiVersion: resources.azure.com/v1api20240101
kind: ResourceGroupTemplateDeployment
metadata:
  name: aks-resource-name
spec:
  owner:
    name: resource-group-rg
  templateContent: |
{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "vnetName": {
            "type": "string",
            "metadata": {
                "description": "Name of the VNET"
            }
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Network/virtualNetworks",
            "apiVersion": "2020-05-01",
            "name": "[parameters('vnetName')]",
            "location": "[resourceGroup().location]",
            "properties": {
                "addressSpace": {
                    "addressPrefixes": [
                        "{{ .Values.vnet.addressSpace }}"
                    ]
                }
            }
        }
    ],
    "outputs": {
      "exampleOutput": {
        "type": "string",
        "value": "someoutput"
      }
    }
}
  deploymentMode: Complete|Partial
  parametersContent: |
{
  "vnetName": {
    value: "{{ .Values.vnet.name }}"
  }
}

This resource could automatically attempt to delete resources deployed by the ARM Template when it is deleted.

The thinking for this resource is that this would allow teams to use resources on Day 0 of release as they are supported in ARM and Bicep and reduce the pressures on getting these resources implemented in ASO.

There would be some caveats:

• The validation that you would normally get from kubectl would not be supported, I think this would be accepted as is if you are using this resource
• The user would need to ensure the ARM template is valid, again this would be accepted as is, as part of using this resource

Other points

• Could the outputs from the ARM template be handled similar to operatorSpec so these could be output to a ConfigMap?
• Could support Bicep as well but that may involve additional work and since Bicep can be converted to ARM may not be necessary

There are possibly some other caveats that would apply to this resource

[theunrepentantgeek]

We think there may be merit in supporting the Deployment resource, but there are a number of complexities around resource ordering, naming, exporting of config-maps/secrets, and so on. We think this would require a full spec in order to flesh out how such a resource would interact with other ASO resources.

For now, we're interested in knowing if other users would be interested in this kind of capability.

[matthchr]

Also consumption of configMaps and secrets - how do you do that?

[matthchr]

We discussed this and agree it's a great one to do. Goal is tentatively to get a rough design for 2.9.0 and then based on that and what it uncovers we will decide what milestone we can land the actual implementation in.

[matthchr]

We should consider if we want stacks or deployments or both (see stacks API https://learn.microsoft.com/en-us/rest/api/resources/deployment-stacks?view=rest-resources-2022-08-01-preview)