Open fplantinga-guida opened 3 months ago
I observe the same behavior.
why the subnet_id and vnet_integration_enabled properties removed in 3.116.0? ` subnet_id - (Optional) The ID of the Subnet where the API server endpoint is delegated to.
vnet_integration_enabled - (Optional) Should API Server VNet Integration be enabled? For more details please visit Use API Server VNet Integration. `
Any update on this one?
Still broken in azurerm 4.10.0
This post mentions it being removed for version 4+ of the provider due to the stable API use requirement: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/4.0-upgrade-guide#aks-migration-to-stable-api
Although not sure why it would be removed in any 3.x
Still think that moving to a stable only
version of the AKS API makes using Terraform with AKS much less practical, and don't think this is the right choice moving forward. Explicit mention of preview features should be good enough for users while still allowing them to play around with preview features using their existing Terraform code.
Is there an existing issue for this?
Community Note
Terraform Version
1.9.5
AzureRM Provider Version
3.116.0
Affected Resource(s)/Data Source(s)
azurerm_kubernetes_cluster
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
When private_cluster_enabled == true and api_server_authorized_ip_ranges variable is set to [], there should be no changes for the api_server_access_profile after the initial run.
Actual Behaviour
The property changes on every terraform run. We can workaround this by removing the entire api_server_access_profile block or using a lifecycle ignore for api_server_access_profile. We use a terraform module to deploy public and private AKS clusters so it would be nice if we can keep the property in the module. I noticed this behaviour changed in version 3.114.0
Steps to Reproduce
Important Factoids
No response
References
No response