Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data: azurerm_kubernetes_cluster crash on v3.106 #26169

Closed
1 task done
BlondeBurrito opened this issue May 31, 2024 · 3 comments · Fixed by #26173
Closed
1 task done

Data: azurerm_kubernetes_cluster crash on v3.106 #26169

BlondeBurrito opened this issue May 31, 2024 · 3 comments · Fixed by #26173

Comments

@BlondeBurrito
Copy link

BlondeBurrito commented May 31, 2024

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.

Terraform Version

1.5.6

AzureRM Provider Version

3.106.0

Affected Resource(s)/Data Source(s)

data.azurerm_kubernetes_cluster

Terraform Configuration Files

variable "aks_name" {
  description = "Name of the AKS device to deploy to"
  type        = string
}

variable "aks_resource_group_name" {
  description = "Name of the resource group containing the AKS device"
  type        = string
}

data "azurerm_kubernetes_cluster" "aks" {
  name                = var.aks_name
  resource_group_name = var.aks_resource_group_name
}

Debug Output/Panic Output

2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: Planning failed. Terraform encountered an error while generating this plan.
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: Error: Plugin did not respond
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66:   with data.azurerm_kubernetes_cluster.aks,
2024-05-31T08:49:52Z logger.go:66:   on data.tf line 1, in data "azurerm_kubernetes_cluster" "aks":
2024-05-31T08:49:52Z logger.go:66:    1: data "azurerm_kubernetes_cluster" "aks" {
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: The plugin encountered an error, and failed to respond to the
2024-05-31T08:49:52Z logger.go:66: plugin.(*GRPCProvider).ReadDataSource call. The plugin logs may contain more
2024-05-31T08:49:52Z logger.go:66: details.
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: Stack trace from the terraform-provider-azurerm_v3.106.0_x5 plugin:
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: panic: runtime error: invalid memory address or nil pointer dereference
2024-05-31T08:49:52Z logger.go:66: [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x5c22ea8]
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: goroutine 121 [running]:
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-provider-azurerm/internal/services/containers.flattenKubernetesClusterDataSourceUpgradeSettings(...)
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-provider-azurerm/internal/services/containers/kubernetes_cluster_data_source.go:1483
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-provider-azurerm/internal/services/containers.flattenKubernetesClusterDataSourceAgentPoolProfiles(0xc002491880?)
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-provider-azurerm/internal/services/containers/kubernetes_cluster_data_source.go:1241 +0xb88
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-provider-azurerm/internal/services/containers.dataSourceKubernetesClusterRead(0x0?, {0x764db40?, 0xc001d4fb00?})
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-provider-azurerm/internal/services/containers/kubernetes_cluster_data_source.go:784 +0x105e
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0x8e76da0?, {0x8e76da0?, 0xc002683ef0?}, 0xd?, {0x764db40?, 0xc001d4fb00?})
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:783 +0x163
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).ReadDataApply(0xc000c808c0, {0x8e76da0, 0xc002683ef0}, 0xc002491700, {0x764db40, 0xc001d4fb00})
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:1015 +0x149
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadDataSource(0xc0005437b8, {0x8e76da0?, 0xc002683e00?}, 0xc0021e4360)
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:1237 +0x366
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadDataSource(0xc001afab40, {0x8e76da0?, 0xc002683650?}, 0xc0014407d0)
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:699 +0x3df
2024-05-31T08:49:52Z logger.go:66: github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadDataSource_Handler({0x82a9940?, 0xc001afab40}, {0x8e76da0, 0xc002683650}, 0xc0029964d0, 0x0)
2024-05-31T08:49:52Z logger.go:66: 	github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:503 +0x169
2024-05-31T08:49:52Z logger.go:66: google.golang.org/grpc.(*Server).processUnaryRPC(0xc000022000, {0x8ea0720, 0xc0017ea9c0}, 0xc00290f8c0, 0xc0017e9140, 0xe71c008, 0x0)
2024-05-31T08:49:52Z logger.go:66: 	google.golang.org/[email protected]/server.go:1374 +0xde7
2024-05-31T08:49:52Z logger.go:66: google.golang.org/grpc.(*Server).handleStream(0xc000022000, {0x8ea0720, 0xc0017ea9c0}, 0xc00290f8c0, 0x0)
2024-05-31T08:49:52Z logger.go:66: 	google.golang.org/[email protected]/server.go:1751 +0x9e7
2024-05-31T08:49:52Z logger.go:66: google.golang.org/grpc.(*Server).serveStreams.func1.1()
2024-05-31T08:49:52Z logger.go:66: 	google.golang.org/[email protected]/server.go:986 +0xbb
2024-05-31T08:49:52Z logger.go:66: created by google.golang.org/grpc.(*Server).serveStreams.func1 in goroutine 55
2024-05-31T08:49:52Z logger.go:66: 	google.golang.org/[email protected]/server.go:997 +0x145
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: Error: The terraform-provider-azurerm_v3.106.0_x5 plugin crashed!
2024-05-31T08:49:52Z logger.go:66: 
2024-05-31T08:49:52Z logger.go:66: This is always indicative of a bug within the plugin. It would be immensely
2024-05-31T08:49:52Z logger.go:66: helpful if you could report the crash with the plugin's maintainers so that it
2024-05-31T08:49:52Z logger.go:66: can be fixed. The output above should help diagnose the issue.

Expected Behaviour

Lookup of AKS resource should be successful

Actual Behaviour

Plugin crashes attempting the data lookup

Steps to Reproduce

Terraform plan against already deployed devices with configuration containing:

data "azurerm_kubernetes_cluster" "aks" {
  name                = var.aks_name
  resource_group_name = var.aks_resource_group_name
}

Note: pinning provider back to 3.105 works

Interesting behaviour, I've pinned the provider to 3.105 and executed a terraform destroy against the deployed resources (this doesn't destroy the cluster itself, that's in a different code base). Now when attempting to deploy completely fresh on 3.106 the data lookups for azurerm_kuberenetes_cluster, azurerm_key_vault and azurerm_subnet exhibit a crash (the cluster, KV and subnet do indeed exist) - whereas when 3.105 had been used for an apply, a plan under 3.106 only encountered a crash for the AKS data lookup.

Further interesting, the 3.106 plan has shifting behaviour, doing a plan the first time the kubernetes and subnet lookups fail:

Error: Plugin did not respond

  with data.azurerm_kubernetes_cluster.aks,
  on data.tf line 1, in data "azurerm_kubernetes_cluster" "aks":
   1: data "azurerm_kubernetes_cluster" "aks" {

The plugin encountered an error, and failed to respond to the
plugin.(*GRPCProvider).ReadDataSource call. The plugin logs may contain more
details.

Error: Plugin did not respond

  with data.azurerm_subnet.subnet,
  on data.tf line 72, in data "azurerm_subnet" "subnet":
  72: data "azurerm_subnet" "subnet" {

The plugin encountered an error, and failed to respond to the
plugin.(*GRPCProvider).ReadDataSource call. The plugin logs may contain more
details.

Stack trace from the terraform-provider-azurerm_v3.106.0_x5 plugin:

Then attempting another plan on 3.106 again without changing anything shows the subnet lookup succeeding and the kuberenetes lookup continuing to fail:

2024-05-31T09:39:49Z logger.go:66: data.azurerm_subnet.subnet: Read complete after 0s

Error: Plugin did not respond

  with data.azurerm_kubernetes_cluster.aks,
  on data.tf line 1, in data "azurerm_kubernetes_cluster" "aks":
   1: data "azurerm_kubernetes_cluster" "aks" {

The plugin encountered an error, and failed to respond to the
plugin.(*GRPCProvider).ReadDataSource call. The plugin logs may contain more
details.

Important Factoids

No response

References

No response

@michelefa1988
Copy link

Not sure if this is related, but I feel my terraform has gone crazy in the last hour. is this the same issue? In my case even master is erroring out meaning there should not be a diff between the infrastructure

image

@manicminer
Copy link
Contributor

Thanks for reporting @BlondeBurrito, this has now been fixed and a patch release v3.106.1 will be issued shortly.

Copy link

github-actions bot commented Jul 1, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants