Invalid plan does not trigger terraform errors

[eviln1]

Hi @mumoshu ; thanks for developing this provider <3

I just started to learn using it and I ran into this issue during terraform plan phase:

--- SNIP ---
2021/01/26 10:48:16 [WARN] Provider "registry.terraform.io/mumoshu/helmfile" produced an invalid plan for helmfile_release_set.helmfile, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .binary: planned value cty.StringVal("helmfile") does not match config value cty.NullVal(cty.String)
      - .helm_binary: planned value cty.StringVal("helm") does not match config value cty.NullVal(cty.String)
      - .dirty: planned value cty.False does not match config value cty.NullVal(cty.Bool)
      - .concurrency: planned value cty.NumberIntVal(0) does not match config value cty.NullVal(cty.Number)
2021-01-26T10:48:16.284+0100 [DEBUG] plugin: plugin process exited: path=.terraform/providers/registry.terraform.io/mumoshu/helmfile/0.13.2/linux_amd64/terraform-provider-helmfile_v0.13.2 pid=44672
2021-01-26T10:48:16.284+0100 [DEBUG] plugin: plugin exited
--- SNIP ---

I would expect that any errors encountered during the plan phase would result in an invalid plan.

This is the setup:

$ terraform version
Terraform v0.14.4
+ provider registry.terraform.io/mumoshu/helmfile v0.13.2

Not 100% what the real error is; from what I can gather so far it's related to KUBECONFIG parsing - looks like it's using the base64 encoded CA as server name; If I can confirm it will open a separate issue.
Thanks again.

[mumoshu]

@eviln1 Hey! Thanks for reporting.

From what I can see from the logs you've shared, it seems like they're internal errors between the helmfile provider and Terraform, not from helmfile. So you can safely assume that the plan is ok. At least those messages are red herring - I'll investigate a bit to suppress them.

Or - do you by any chance have another log that indicates that the plan is actually failing due to KUBECONFIG parsing as you mentioned? I'd appreciate it if you could share another log if there's any!

[eviln1]

Thanks alot @mumoshu .
So the error I had made specifically was:

resource "helmfile_release_set" "helmfile" {
  version           = "0.137.0"
  helm_version      = "3.5.0"
  helm_diff_version = "v3.1.3"
  content           = file("${path.module}/helmfile.yaml")
  kubeconfig        = file("${path.module}/kubeconfig")  # <-- this;
 }

The kubeconfig file is a standard EKS generated kubeconfig file; The result was that helmfile was unable to connect to the EKS cluster; the diff_output was empty, but it did not end up in an invalid terraform plan.
I can share scrubbed logs, but I think it's pretty easy to reproduce. Let me know if you think you still need them.

[mumoshu]

@eviln1 Thanks for the response! It's confusing but kubeconfig must be the path to your kubeconfig file, rather than the content of it.

[mumoshu]

And there's some logic in the provider that prevents tf from producing an invalid plan when the specified kubeconfig file doesn't exist, as tf gives us an empty string for kubeconfig on terraform plan when it has a computed value rather than a concrete value. If we emitted invalid plan for an empty or invalid file path, terraform plan can never succeed when kubeconfig has a computed value.

Maybe we can improve this by, e.g. checking if the kubeconfig value is something like a file path or not, and emit a invalid plan error with a more concise message, like kubeconfig seems to have invalid value, it must be a path to file

[eviln1]

Ok I understand better.
That would be helpful, it took me a couple of loops to figure out what I was doing wrong.
Thanks alot.