azurerm_application_insights support for updating workspace_id impacted by upcoming Classic App Insights Auto-Migration

[qinjoshua]

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.

Description

We're from the Microsoft Application Insights team, and we are working on an effort to automatically migrate all customers using Classic Application Insights to Workspace-Based Application Insights resources.

Classic Application Insights was deprecated in 2021, and it was retired in February 2024. The main difference between Classic and Workspace-Based Application Insights was that Classic Application Insights did not have Workspace Resource ID; now that Classic Application Insights is being migrated, in the future it will not be valid for any Application Insights resource to be missing a Workspace Resource ID.

To avoid disrupting existing deployment scripts, we are planning on continuing to allow customers to use deployment scripts that do not specify a Workspace Resource ID, with new behaviors. Once the migration begins, customers who do not provide a Workspace Resource ID will have an Log Analytics Workspace automatically created and assigned, which will show up as part of the response JSON.

However, this new behavior could cause a conflict if the user applied a terraform script to create Application Insights resources without specifying a Workspace Resource ID, and then try to apply changes using the same deployment script. Terraform expects the Workspace Resource ID to be empty, but Azure has assigned the Application Insights resource a Workspace Resource ID post-deployment. Terraform will think that the user is trying to switch from Workspace-Based Application Insights to Classic Application Insights, and the Terraform validation logic will throw and error and block the deployment. This validation logic was added in this PR.

Our suggestion is that in future versions of Terraform, Terraform should only attempt to apply changes to the workspace_id if the user's deployment script explicitly specifies a workspace_id. If the user's deployment script does not specify a workspace_id, but one exists in Azure, this should not be considered a change and should be ignored. This way, customers will not have to use the workaround and can continue to avoid specifying their own workspace while allowing Azure to generate its own. We're happy to contribute a PR to implement our proposed change, if this sounds good to the Terraform team.

Workaround

Add workspace_id to ignore_changes in order for your deployment script to ignore provider-assigned values to workspace resource ID.

Example:

resource "azurerm_application_insights" "example" {
   name                = <name>
   location            = <location>
   resource_group_name = <resource_group>
   application_type    = "web"

   lifecycle {
      ignore_changes   = [workspace_id]
   }
}

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

azurerm_application_insights

Potential Terraform Configuration

No response

References

#21029
#20968

[teowa]

Hi @qinjoshua , thanks for the issue! I have submitted #27637 to update the error message and doc for server side automatic workspace migration.

[qinjoshua]

Hi @teowa
Thank you for your quick response! I appreciate the workaround you provided in the error message, which seems to be the best way for existing customers to fix their existing deployment scripts. To copy it in this thread for visibility, in order to prevent this error from showing up when Workspaces generated automatically, workspace_id should be added to ignore_changes.

However, we're actually interested in changing the default behavior for all future versions of Terraform going forward, because even after the migration customers will still be allowed to create Application Insights without specifying a Workspace Resource ID - we will just assign one for them. Following the advice from this GitHub question, it seems like what we want is to add the property Computed: true under this line in the Application Insights component schema. The intended behavior here is that customers should be allowed to specify a workspace_id, but if they do not specify one explicitly, one will be assigned. Are those the correct changes to make to achieve that pattern, or is there anything else that needs to be done?

[teowa]

Hi @qinjoshua , thanks for the additional details. I should have mentioned earlier that the provider no longer accepts properties that are both optional and computed, and it is gradually transitioning existing O+C properties, as documented here: https://github.com/hashicorp/terraform-provider-azurerm/blob/main/contributing/topics/best-practices.md#setting-properties-to-optional--computed. For now, we can only advise users to add this to ignore_changes or manually set the generated workspace ID.

[qinjoshua]

Thank you for the response! That makes sense, and I think the ignore_changes solution will be sufficient for our customers under the new solution.

Edited the workaround section above for visibility

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.