Terraform: Failed to parse terraform_remote_state etcdv3 config block

[rocketspacer]

Terraform Version

Terraform v0.11.7

Terraform Configuration Files

data "terraform_remote_state" "foo" {
    backend = "etcdv3"
    config {
        endpoints = ["<valid-etcdv3-endpoint>:2379"]
        lock      = true
        prefix    = "terraform-state/"
    }
}

Debug Output

https://gist.github.com/rocketspacer/94f12ba802ae03e527aa6c82f1c50a58#file-terraform_debug_log_1534130886787

Crash Output

Expected Behavior

It should have successfully pulling the terraform_remote_state data source

Actual Behavior

Terraform errored out and say that config (endpoints) is expected to be a string, while it is clearly documented to be an array https://www.terraform.io/docs/backends/types/etcdv3.html#example-referencing

Error: data.terraform_remote_state.foo: config (endpoints): '' expected type 'string', got unconvertible type '[]interface {}'

Steps to Reproduce

terraform init

terraform apply

Additional Context

References

[rocketspacer]

It fails very fast actually, doesn't even need a <valid-etcdv3-endpoint> to verify this

[pljanot]

Got exactly same error on version: Terraform v0.11.8
Is there any workaround for this ?

[apparentlymart]

Hi @rocketspacer and @delvier! Sorry for this annoying limitation.

The terraform_remote_state data source in v0.11 and earlier only supports string configuration keys, due to limitations of the provider SDK. In practice most of the backends only _have_ string configuration keys, so this wasn't an obvious problem until the integration of the etcdv3 backend, and later the new experimental "remote" backend (which has a nested block in its configuration).

This is one of the things we've tried to address for the forthcoming v0.12.0 release, and the intended fix is already in master so I'm going to add this to the v0.12.0 milestone just as a prompt for us to verify that this example will indeed work in the new release.

Unfortunately I can't think of a workaround off the top of my head for this one. :confounded: There are two validation rules in conflict here, and so I expect that even if you _did_ pass in a string to get past the terraform_remote_state validation you'd then get an error from the backend itself saying that the argument ought to be a list.

I think the best we can do here is make sure this is fixed in the next release. Sorry about that! Thanks for reporting this.

[pljanot]

@apparentlymart thank you for your comment, waiting forward for a new release.

[apparentlymart]

Hi again, all!

As promised, I just verified this against the v0.12.0-alpha2 prerelease build, using the following configuration:

data "terraform_remote_state" "foo" {
  backend = "etcdv3"
  config = {
    endpoints = ["127.0.0.1:2379"]
    lock      = true
    prefix    = "terraform-state/"
  }
}

I don't have an etcd server handy to test against, so I just watched Terraform's logs and verified that it was getting far enough to try to request the state here, which it did. This confirms that these settings are now passing validation and getting passed through to the backend implementation.

Since the original problem here also included a crash due to incomplete validation of the configuration, I also wanted to check an _invalid_ case to see what would happen, and so I just put list brackets around the lock value so it would be incorrectly typed as a list instead of a bool:

Error: Invalid backend configuration

  on etcd-remote-state.tf line 3, in data "terraform_remote_state" "foo":
   3:   config = {
   4:     endpoints = ["127.0.0.1:2379"]
   5:     lock      = [true]
   6:     prefix    = "terraform-state/"
   7:   }

The given configuration is not valid for backend "etcdv3": .lock: bool
required.

Terraform correctly detected that the type of that argument was incorrect and returned a proper error for it, rather than crashing.

Since these fixes are already in the master branch and ready for inclusion in the forthcoming v0.12.0 release, I'm going to close this out now. Thanks for reporting this, and sorry for the delay in getting it fixed.