terraform-provider-kubernetes icon indicating copy to clipboard operation
terraform-provider-kubernetes copied to clipboard

Why doesn kubernetes provider's data block behavior on nonexistent resources differs from other terraform providers

Open L1ghtman2k opened this issue 10 months ago • 2 comments

Based on the discussion: https://github.com/hashicorp/terraform/issues/16380

The expectation is that terraform provider should fail on the data block if the resource addressed by the data block doesn't exist. This is not the behavior of terraform kubernetes provider. As a result, I can no longer assume data blocks could be used as assertions that the referenced infrastructure exists. Could there be an opt-in feature on the provider to allow for this behavior?

terraform plan for the following block

data "kubernetes_service_account" "my_svc" {
  metadata {
    name      = "my_svc"
    namespace = "kafka"
  }
}

output "instance_ip_addr" {
  value = data.kubernetes_service_account.my_svc
}

yields following output:

  + instance_ip_addr = {
      + automount_service_account_token = null
      + default_secret_name             = null
      + id                              = "/"
      + image_pull_secret               = null
      + metadata                        = [
          + {
              + annotations      = {}
              + generation       = 0
              + labels           = {}
              + name             = "my_svc"
              + namespace        = "kafka"
              + resource_version = ""
              + uid              = ""
            },
        ]
      + secret                          = null

even though the SA doesn't exist.

Terraform version, Kubernetes provider version and Kubernetes version

Terraform version: OpenTofu v1.8.1
Kubernetes Provider version: v2.30.0
Kubernetes version: 1.25.12

Edit: seems like overtime there has been a number of other providers that had similar issues, though, the general consensus is that data blocks should return an error, and some providers have since fixed the incorrect behavior: https://github.com/hashicorp/terraform-provider-azurerm/pull/1223

L1ghtman2k avatar Jan 17 '25 20:01 L1ghtman2k

And I want to add on top of this one, that using your generic data provider we get the expected behavior:

data "kubernetes_resource" "namespace" {
  api_version = "v1"
  kind        = "Namespace"
  metadata {
    name = var.aks.service_account_namespace
  }
}

Although the error can be misleading and should be improved

Planning failed. Terraform encountered an error while generating this plan.

╷ │ Error: Provider produced null object │ │ Provider "provider["registry.terraform.io/hashicorp/kubernetes"]" produced a null value for module.this.data.kubernetes_resource.namespace. │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker. ╵

In this case clearly is not a bug, because the resource doesn't exist.

So why using a dedicated data source for namespace we still get an object with just the name we provided in it, when it doesn't exist?

pacorreia avatar Jan 20 '25 11:01 pacorreia

Hey team, is this one going somewhere, noticed it was acknowledged, but is there anything else?

pacorreia avatar Apr 08 '25 08:04 pacorreia