Support for `kind="AIServices"` in `azurerm_cognitive_account`

[jamesmcroft]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Description

The azurerm_cognitive_account does not support the AIServices kind, a new type provided for the collective AI services that power the Azure AI Studio hub.

New or Affected Resource(s)/Data Source(s)

azurerm_cognitive_account

Potential Terraform Configuration

resource "azurerm_cognitive_account" "ai_services" {
  kind = "AIServices"
}

References

No response

[rmcolbert]

@tombuildsstuff Can we revisit closed PR from April #25662? The ARM template for the AIServices kind of a cognitive account is exactly the same for the other cognitive accounts (see below). The only difference between AIServices and the CognitiveServices kind is that AIServices adds that ability to use OpenAI services in the account with the older CognitiveServices types.

        {
            "apiVersion": "2022-03-01",
            "name": "[parameters('name')]",
            "location": "[parameters('location')]",
            "type": "Microsoft.CognitiveServices/accounts",
            "kind": "AIServices",
            "tags": "[if(contains(parameters('tagValues'), 'Microsoft.CognitiveServices/accounts'), parameters('tagValues')['Microsoft.CognitiveServices/accounts'], json('{}'))]",
            "sku": {
                "name": "[parameters('sku')]"
            },
            "properties": {
                "customSubDomainName": "[toLower(parameters('name'))]",
                "publicNetworkAccess": "[if(equals(parameters('virtualNetworkType'), 'Internal'), 'Disabled', 'Enabled')]",
                "networkAcls": {
                    "defaultAction": "[if(equals(parameters('virtualNetworkType'), 'External'), 'Deny', 'Allow')]",
                    "virtualNetworkRules": "[if(equals(parameters('virtualNetworkType'), 'External'), json(concat('[{\"id\": \"', concat(subscription().id, '/resourceGroups/', parameters('vnet').resourceGroup, '/providers/Microsoft.Network/virtualNetworks/', parameters('vnet').name, '/subnets/', parameters('vnet').subnets.subnet.name), '\"}]')), json('[]'))]",
                    "ipRules": "[if(or(empty(parameters('ipRules')), empty(parameters('ipRules')[0].value)), json('[]'), parameters('ipRules'))]"
                }
            },
            "dependsOn": [
                "[concat('Microsoft.Resources/deployments/', 'deployVnet')]"
            ]
        },

[jamesmcroft]

@rmcolbert there is an open PR based on the feedback to split out the AI Services resource into its own template - #26008

[rmcolbert]

I know there is a PR to split it out. I'm questioning why. All of the other tooling (Azure PowerShell, Az CLI, Bicep and ARM) have this under the same resource/noun/type because the actual resource is simply a cognitive services account. The only difference between this and the existing "CognitiveServices" kind already in the provider is the additional ability to deploy models (which is already handled under the azurerm_cognitive_deployment resource).

So my question is why are we splintering the consistency between tooling options?

[cmaclaughlin]

Although you are correct that the primary difference between kind CognitiveServices and AIServices is the inclusion of Azure OpenAI, this has implications when creating service connections between the Cognitive Service Account and an Azure AML workspace, AI Studio Hub and/or AI Studio Project.

With kind AIServices, when the service connection is created for said kind, then both a "normal" connection AND an Azure OpenAI connection are created behind the scenes.

With kind CognitiveServices, users would need to create a service connection just for Cognitive Services. Then, a service connection exclusively for Azure OpenAI would need to be provisioned. It is unclear whether additional steps would be required before creating a service connection at this time.

[rmcolbert]

@cmaclaughlin, in the scope of this issue (azurerm_cognitive_account), does that subtlety matter? I would presume there should be a specific azurerm_cognitive_account_connection resource for establishing links to the AML workspace similar to azurerm_private_endpoint. Especially since there are now two different resources for creating a cognitive account.

[cmaclaughlin]

@rmcolbert - I might've missed something & I apologize if that's the case.

Is the intent that azurerm_cognitive_account be used if, and only if, creating a resource of any kind other than AIServices and that azurerm_ai_services is used only for kind AIServices?

Your comment re: not splintering made sense and, so, I expected that the lack of AIServices as a valid kind meant this issue was still relevant.

[rmcolbert]

@cmaclaughlin I think it is mildly silly to split AIServices off from the rest of the cognitive_account kinds since it is the combination of the OpenAI and the CognitiveServices kinds (unless they are going to create a unique resource for each). To your point, there isn't a native way to create the service connections at all right now and there would need to be extra care taken in that resource type for the distinction.