Terraform: Errors in module names not reported correctly.

[JakeLogemann]

It appears TF does not support hyphens (-) in module names correctly. I created a module named aws-s3 to provision an AWS/S3 instance which resulted in this cryptic error:

+ terraform plan -state=.terraform.tfstate -var-file=terraform.tfvars
Errors:
  * module root: module aws-s3: access_key is not a valid parameter

The module's parameters are correctly defined in contrib/aws-s3/variables.tf and the module works fine in isolation. This error only seems to occur when using aws-s3 as a submodule. Interestingly, multiple runs result in different parameters causing the error.

Originally, I used the release version. After spending a few days trying to figure it out, I checked out the master branch to no avail, the exact same error occurred. After some self-doubt, I started googling.

Someone mentioned that they had a problem with hypens in module attributes. By changing the name of my module to aws_s3 all my errors vanished and everything has worked wonderfully since.

Issue is solved for me, but future users may benefit from a more helpful error message.

[phinze]

Sorry for the bad UX here, and thanks for reporting. We'll definitely get this fixed up so it either works or a sane error message shows up. :ok_hand:

[mitchellh]

I've tried this in all sorts of various ways from master and I can't seem to reproduce this. Can you outline specific steps and example files and I'll try again? Closing until then.

[HarrisonJackson]

@JakeLogemann did you ever find a way around this? I am experiencing this issue as well. If I run terraform plan from within the module directory it prompts me for each of the inputs and spits out the plan, but when I try to use it as a module it tells me a different parameter is not valid each run.

[HarrisonJackson]

I was able to get past this by wiping my directory and recloning - I suspect it had something to do with the .terraform dir keeping something cached even after performing terraform get. These were local modules, that I was referencing. Hope that helps someone.

[larry-svds]

rm -r .terraform

did the trick for me.

Thanks for the tip. I started having this issue. Also with a module with "-" in it. Not sure if that was the problem or if there is some other edge case that corupts teh .terraform cache directory.

[mboret]

I've just encounter this issue. It's clearly a random issue because, I've already use the "-" in module name for other projects without error.

More strange is:

1) With the "-" in module name I've "is not a valid parameter"
2) I've replaced all my "-" by "_" and terraform plan works
3) I'd rollback my modifications.... and it still works!

[PetaPetaPeta]

Be very careful with the rm -r .terraform. It might contain some symbolic references to your modules. Be sure to back up you work before doing this.

[danielbryantuk]

Hey @mitchellh, I've just bumped into this issue today as well. I've created a toy example that I believe demonstrates the problem:

https://github.com/danielbryantuk/terraform_modules

Simply clone, add credentials for GCP, and 'terraform plan'.

When I do this I see this error:

module root: module module-a: name is not a valid parameter

[danielbryantuk]

Apologies - ignore me @mitchellh. Upon reflection, this looks like a misunderstanding by me from reading the docs at https://www.terraform.io/docs/modules/usage.html

From quickly reading the module docs I assumed 'name' was a standard property of the 'module' type, but it clearly isn't! As soon as I add the variable "name" {} to the tf files within each of my modules the issue disappears.

Hopefully this comment can be a warning to anyone else who lands here after searching the web for 'terraform name is not a valid parameter' :-)

[u2mejc]

For those of you with OP's issue and who agree that renaming the module (forces new resources), nor destroying your local state (dangling resources or hassle with remote state setup again) are good resolutions to this issue, you can also surgically remove the module(s):

$ rm -fR .terraform/modules/*
$ terraform get

This will should allow the corrupt module to download again.

Note to future debugging: Issue reproduced in 0.7.13 and 0.8.4 when a module was updated to add a list variable that would be interpolated by a terraform.tfvars file.

[mhmdio]

face it when updating from 0.8.4 to 0.8.5, if anyone upgrading, consider the above approach

[HebertCL]

I've found this same issue for v0.8.6, v0.8.5 and v0.8.4, it seemed to be a random behavior since both renaming my module without "-" and deleting .terraform/modules folder workarounds did not solve my issue. In my particular case I had this issue with resource aws_auto_scaling_group. My module was::

module "appservers" {
source = "git::[email protected]:HebertCL/demo-app-server-module.git"

    min_size = 2
    max_size = 2
    desired_capacity = 2

}

I faced the same behavior described above, and it somehow solved until I removed the desired capacity field from both asg and module. I don't know if this is just a random occurrence or just Terraform throwing a confusing error making me remove redundant options from my code. Either way, we would appreciate you checking this error once again.

[sbatchu0108]

I ran into same issue. rm -r .terraform did the trick for me.

[ahasnaini]

same thing for me as well, had to delete .terraform folder. spent a lot of time reviewing all the files to find the missing parameter. t

[lajoie]

I ran into this same issue with version 0.9.11

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.