App insights Application type (kind) may not be supported

[websolut]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", 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.

We have been deploying app insights with kind = MobileCenter as per documentation.

When we tried to do some ad hoc changes via powershell we saw this error

Update-AzApplicationInsights -Name "g" -ResourceGroupName "sb1" -DisableIPMasking:$true
Update-AzApplicationInsights: Cannot validate argument on parameter 'Kind'. The argument "MobileCenter" does not belong to the set "web,other,nodejs,java,ios,store,phone" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command again.

As per TF documentation -
application_type - (Required) Specifies the type of Application Insights to create. Valid values are ios for iOS, java for Java web, MobileCenter for App Center, Node.JS for Node.js, other for General, phone for Windows Phone, store for Windows Store and web for ASP.NET. Please note these values are case sensitive; unmatched values are treated as ASP.NET by Azure. Changing this forces a new resource to be created.

Terraform Version

1.75

AzureRM Provider Version

3.111

Affected Resource(s)/Data Source(s)

azurerm_application_insights

Terraform Configuration Files

resource "azurerm_application_insights" "application_insights" {

  name                = var.appinsights_name
  location            = var.appinsights_location
  resource_group_name = var.appinsights_resource_group_name
  application_type    = var.appinsights_application_type
  sampling_percentage = 100

  workspace_id = var.appinsights_workspace_based ? var.loganalytics_id : null

  internet_ingestion_enabled = var.appinsights_secure_in_vnet ? false : true
  internet_query_enabled     = true 

}

az CLI documentation states:
--kind -k
The kind of application that this component refers to, used to customize UI. This value is a freeform string, values should typically be one of web, ios, other, store, java, phone.

--application-type
Type of application being monitored. Possible values include 'web', 'other'. Default value is 'web' .

Default value: web

Debug Output/Panic Output

Deployment is OK

Expected Behaviour

No response

Actual Behaviour

We should be able to manage the service created with TF via powershell or az cli

Steps to Reproduce

No response

Important Factoids

No response

References

No response

[ned1313]

Looking at the API and the provider code, there are two fields at play here: application_type and kind. These are distinct fields in the API.

• application_type has two valid values: web and other
• kind is a free-form string field, but should be one the listed types from here

The application_type argument in the provider allows for the following values:

                                        "web",
					"other",
					"java",
					"MobileCenter",
					"phone",
					"store",
					"ios",
					"Node.JS",

The provider uses the same value for application_type and kind, and it doesn't look like the API validates the value for application_type. However, PowerShell and az cli do appear to check for valid values in the application_type field, hence the error.

I think the correct fix is to add kind as an argument for the resource. It can be optional, and use the application_type value if its not set. The application_type should be limited to the two values (web and other) specified by the API docs. This would be a breaking change.

The alternative is to add logic that does the following:

• If application_type is web: recording web in state and use web for both application_type and kind when sending the create or update request.
• if the application_type is anything else: record the value in state, use other for application_type and the value for kind when sending the create or update request

There will also need to be similar logic for the read function to transform the data back for proper comparison. This would be a breaking change as all existing deployments that don't use web would have their application_type value changed, which appear to force a recreation.