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

kubernetes_persistent_volume_claim_v1 data object does not work with depends_on

Open ZoeSecondmind opened this issue 2 years ago • 1 comments

Terraform Version, Provider Version and Kubernetes Version

Terraform version: v1.5.7
Kubernetes provider version: v2.23.0
Kubernetes version: v1.25.10-gke.1200

Affected Resource(s)

  • kubernetes_persistent_volume_claim_v1

Terraform Configuration Files

resource "kubernetes_namespace" "testing" {
  provider = kubernetes
  metadata {
    name = local.namespace
  }
}

data "kubernetes_persistent_volume_claim_v1" "testing" {
  depends_on = [ kubernetes_namespace.testing ]
  metadata {
    namespace = local.namespace
    name      = local.pvc_name
  }
}

data "kubernetes_persistent_volume_v1" "testing" {
  metadata {
    name = data.kubernetes_persistent_volume_claim_v1.testing.spec[0].volume_name
  }
}

Debug Output

(https://gist.github.com/ZoeSecondmind/d953a9b61139be57fbaf50ce2991b438)

Steps to Reproduce

  1. terraform plan

Expected Behavior

Successful plan, assuming the supplied PVC already exists.

Actual Behavior

data.kubernetes_persistent_volume_claim_v1.testing.spec is empty list of object error returned. This error disappears if the depends_on = is removed.

References

  • GH-1234 details a similar issue with a terraform-provider-tls resource, which turned out to be a provider rather than terraform issue, hence opening here.

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

ZoeSecondmind avatar Oct 02 '23 16:10 ZoeSecondmind

The issue happens with me regardless if using depends_on or not.

Additional Details

Versions

Terraform v1.6.4 on linux_amd64
provider registry.terraform.io/hashicorp/kubernetes v2.24.0
k8s: AKS v1.26.6

Example

data "kubernetes_persistent_volume_claim_v1" "claim_to_disk" {
  metadata {
    name             = "<redacted>-0"
    namespace        = "<redacted>"
    #name      = local.volumeclaim_name
    #namespace = local.volumeclaim_namespace_name
  }
}

data "azurerm_managed_disk" "disk_to_backup" {
  name                = "pvc-345ba363-<redacted>"
  #TODO: uncomment when this issue is resolved: https://github.com/hashicorp/terraform-provider-kubernetes/issues/2305
  #name                = data.kubernetes_persistent_volume_claim_v1.claim_to_disk.spec[0].volume_name
  resource_group_name = local.configuration.compute_resourcegroup_name
}

Plan Output

Error: Invalid index

  on ../../../modules/templates/backup_policy/data.tf line 11, in data "azurerm_managed_disk" "disk_to_backup":
  11:   name                = data.kubernetes_persistent_volume_claim_v1.claim_to_disk.spec[0].volume_name
    ├────────────────
    │ data.kubernetes_persistent_volume_claim_v1.claim_to_disk.spec is empty list of object

The given key does not identify an element in this collection value: the collection has no elements.

Object in the state

data "kubernetes_persistent_volume_claim_v1" "<redacted>" {
    id = "<redacted>/<redacted>-0"

    metadata {
        annotations      = {}
        generation       = 0
        labels           = <redacted>
        name             = "<redacted>-0"
        namespace        = "<redacted>"
        resource_version = "34246249"
        uid              = "345ba363-<redacted>"
    }

    spec {
        access_modes       = [
            "ReadWriteOnce",
        ]
        resources          = [
            {
                limits   = {}
                requests = {
                    "storage" = "16Gi"
                }
            },
        ]
        storage_class_name = "managed-csi-premium-zrs-noretain"
        volume_name        = "pvc-345ba363-<redacted>"
    }
}

No idea how to work around this issue, except hardcoding the volume_name where needed. It doesn't make sense to me as the data object in the state seems to be properly loaded. I do find strange that spec is considered a list of objects...

fabio-s-franco avatar Jan 03 '24 10:01 fabio-s-franco