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

kubectl_path_documents provides inconsistent output #63

Closed
jorgemoralespou opened this issue Oct 16, 2023 · 1 comment
Closed

kubectl_path_documents provides inconsistent output #63

jorgemoralespou opened this issue Oct 16, 2023 · 1 comment

Comments

@jorgemoralespou
Copy link

jorgemoralespou commented Oct 16, 2023

I'm reading a set of manifests in multiple iterations via kubectl_path_documents and some modules error with:

  on 11-cert-manager.tf line 52, in resource "kubectl_manifest" "app_package_installs_certmanager_package":
  52:   for_each  = var.apply_educates_k8s_resources ? data.kubectl_path_documents.app_package_installs_certmanager_manifests.manifests : {}
    ├────────────────
     │ data.kubectl_path_documents.app_package_installs_certmanager_manifests.manifests is a map of string, known only after apply var.apply_educates_k8s_resources is true

The "for_each" map includes keys derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.

When working with unknown values in for_each, it's better to define the map keys statically in your configuration and place apply-time results only in the map values.

Alternatively, you could use the -target planning option to first apply only the resources that the for_each value depends on, and then apply a second time to fully converge.

I have tried to make a reproducer in a standalone project, and everything was working fine. What I noticed was that if I then added a depends_on to the kubectl_path_documents to every resource data so that I guaranteed that the kubectl provider was initialized, then all of them errored out.

My conclusion is that this data_source_type is dependant on the cluster and hence if processed after there's an actual kubectl provider configuration, then result may vary. While this function only processes manifests from the local file system, it should always produce same output, and not depend on kubectl provider connection.

@jorgemoralespou
Copy link
Author

My bad, it seems there's a variable that depends on random module, so only until it's applied can be calculated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant