Feature Request: Add a flag to disable resource requiring API access during planning time

[gnall-bah]

Description

On the official documentation it states that the kubernetes_manifest resource requires API access at planning time, why is this a thing? It would be amazing if this provider had a flag to turn this off and instead let it fail at apply time. If I want to create a CRD at the same time as deployment I need to use a third party provider. I would prefer to use this provider but I'm limited by this functionality. I can't imagine I'm the only person that ever requested this.

Multi-stage deployments aren't a solution, they are a workaround.

Proposed variable ignore_api_check_at_planning to disable this.

Potential Terraform Configuration

resource "kubernetes_manifest" "ipaddresspool" {
  depends_on = [ helm_release.metallb ]
  ignore_api_check_at_planning = true
  manifest = {
    apiVersion = "metallb.io/v1beta1"
    kind = "IPAddressPool"

    metadata = {
      name = "pool-01"
      namespace = "${helm_release.metallb.namespace}"
    }

    spec = {
      addresses = ["${var.metallb_addresses}"]
    }
  }
} 

References

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

[alexsomesan]

On the official documentation it states that the kubernetes_manifest resource requires API access at planning time, why is this a thing?

The reason this is a thing is because Terraform, internally uses a type-system to structure resource state data on. This is used in the communication protocol with providers, the internal in-memory structures of Terraform as well as state storage.

Terraform expects that a resource's schema and attributes' types stay consistent throughout its lifecycle and has checks in place to enforce this.
In order support CRDs (with their dynamic and ephemeral schemas) and also abide by the type consistency expectations of Terraform, we have to look up the schema of a resource (CR) dynamically during the planning, so that we can return it's corresponding type to Terraform accordingly.

There is no way around this limitation at the moment if we want to keep supporting CRD / CR resources.

The best way to avoid running into this is to split the CRDs outside of the main bulk of resources and apply them beforehand. This should be fairly easy to accomplish in any CI/CD environment.

Terraform core is exploring opportunities to address this limitation, and the solution will come from them.