Terraform Apply fails with "for_each" value cannot be determined until apply

[vara-bonthu]

Hi

I am trying to install flux using this provider example and I am hitting the following error when i run terraform apply

│ Error: Invalid for_each argument
│ 
│   on ../../../modules/kubernetes-addons/fluxcd/main.tf line 15, in resource "kubectl_manifest" "apply":
│   15:   for_each   = { for v in local.install : lower(join("/", compact([v.data.apiVersion, v.data.kind, lookup(v.data.metadata, "namespace", ""), v.data.metadata.name]))) => v.content }
│     ├────────────────
│     │ local.apply will be known only after apply
│ 
│ The "for_each" value depends on resource attributes that cannot be determined until apply,
│ so Terraform cannot predict how many instances will be created. To work around this, use
│ the -target argument to first apply only the resources that the for_each depends on.

I think the issue is with this block where for_each value cannot be determined until apply. Am i missing something?

locals {
  install = [ for v in data.kubectl_file_documents.install.documents : {
    data: yamldecode(v)
    content: v
  }
  ]
}
# Apply manifests on the cluster
resource "kubectl_manifest" "apply" {
  for_each   = { for v in local.install : lower(join("/", compact([v.data.apiVersion, v.data.kind, lookup(v.data.metadata, "namespace", ""), v.data.metadata.name]))) => v.content }
  depends_on = [kubernetes_namespace.flux_system]
  yaml_body = each.value
}

Here is my Terraform version

▶ terraform version 
Terraform v1.0.9
on darwin_amd64
+ provider registry.terraform.io/fluxcd/flux v0.9.0
+ provider registry.terraform.io/gavinbunney/kubectl v1.13.1
+ provider registry.terraform.io/hashicorp/aws v3.73.0
+ provider registry.terraform.io/hashicorp/helm v2.4.1
+ provider registry.terraform.io/hashicorp/kubernetes v2.7.1

It would be really good if we have a Helm Chart for deploying the Flux V2.

[mwalczykpl]

Hi I had the same issue, but my module bootstrapping Fluxcd had dependency to other module (creating cluster). After removing dependency (and creating cluster in another module) error didn't show again.

#resource "null_resource" "kind-cluster" {
#  provisioner "local-exec" {
#    command = "kind create cluster --name ${var.application_name}"
#  }
#}

module "flux-bootstrap" {
  source = "../modules/flux-bootstrap"
  branch = "main"
  deploy_key_name = "${var.application_name}-deployment"
  github_owner = var.github_owner
  repository_name = var.application_name
  target_path = "clusters/development"
#  depends_on = [null_resource.kind-cluster]
}

[mike-morr]

How do we make our custom flux module wait for the cluster to be built if we can't use depends_on in the module definition?

[vara-bonthu]

I would prefer Helm chart to deploy Flux V2 over these manifests.

I came across this one https://github.com/fluxcd-community/helm-charts. Looking forward to try this one

[bravecobra]

I'm hitting the same issue. You cannot have locals depend on data sources in terraform as data sources are only read upon apply. Thus terraform plan will always fail. These examples are flawed when used in a module.

[bravecobra]

The relevant documentation why this fails, is explained here: https://www.terraform.io/language/meta-arguments/for_each#limitations-on-values-used-in-for_each

[sytgj7896321]

I think it can be solved by null_resource

module "foo" {
   ... 
)

resource "null_resource" "bar" {
  triggers = {
    some_output = module.foo.some_output
  }
  depends_on = [module.foo]
}

module "flux" {
  ...
  some_parameter = null_resource.bar.triggers.some_output
}

The output and parameter can be meaningless, just for building a relationship

[leosunmo]

That null_resource trick doesn't seem to work for me. I'd love a workaround for this!

[Sokratis1904]

+1

[swade1987]

Hi @vara-bonthu 👋

I hope you are doing well! As part of our ongoing effort to maintain and improve the quality of our project, I've been reviewing open issues and came across the one you've reported. First off, thank you for taking the time to contribute by reporting this issue; your input is crucial to us.

Upon reviewing the details of your issue, I noticed that it involves the use of a resource or feature that has yet to be supported since the 1.0.0 release of our project, which was approximately 9 months ago. This might be a key factor in the challenges you're experiencing. We understand that changes and deprecations can impact your work, and we're here to help navigate these transitions. If there are specific reasons you've continued using this unsupported resource or if there's any way we can assist in migrating to a supported alternative, please let us know.

Additionally, to ensure the efficient management of our issue tracker and to focus on issues that are actively affecting our community, we have implemented a policy for issues that remain inactive. If there is no activity on this issue within the next 3 weeks, we will consider the issue inactive and close it for you. This doesn't mean your issue is not important to us, but rather that we aim to keep our focus on actively pursued concerns. Of course, if the issue continues or if you have further updates in the future, feel free to reopen the issue or create a new one.

Thank you once again for your contribution to our project. Your feedback not only helps us improve but also supports the broader community in overcoming similar challenges. We look forward to hearing from you and hope to resolve any outstanding concerns together.

Best regards,

Steve