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

Accept maps as provider blocks #9747

Closed
moio opened this issue Oct 31, 2016 · 3 comments
Closed

Accept maps as provider blocks #9747

moio opened this issue Oct 31, 2016 · 3 comments

Comments

@moio
Copy link
Contributor

moio commented Oct 31, 2016

Terraform Version

Latest 0.7.7

Affected Resource(s)

Core.

Terraform Configuration Files

Example on AWS:

resource "aws_instance" "web" {
   ...
   ebs_block_device = "${var.device}"
}

Expected Behavior

Assuming ${var.device} is a map with keys corresponding to the expected keys, the definition is equivalent to an inline one.

Actual Behavior

Type error: got map while expecting object.

Steps to Reproduce

terraform plan

Important Factoids

This first came up while developing a libvirt provider, where we do not have an equivalent of the volume_attachment resources.

Question is: should such a resource really be added to the provider, or is this a core Terraform issue that will eventually be solved at language level?

@apparentlymart
Copy link
Contributor

Hi @moio! Sorry for the long silence here.

I think this issue is covering the same use-cases as #7034, which has now been closed due to a new feature merged into master for inclusion in the forthcoming v0.12.0 release. I've left a comment over there illustrating how it works.

Thanks for requesting this, and sorry we didn't catch it on earlier updates.

@moio
Copy link
Contributor Author

moio commented Nov 7, 2018

Hey @apparentlymart! This is actually fantastic news and I can't wait to jump on v0.12 to enjoy all the new constructs and facilities.

Please accept my personal thanks and feel free to relay them to the whole team too - we know very well that sometimes it's best to wait for the right architectural solution to solve a broad range of issues instead of just adding hacks here and there and ending up with an unmaintanable mess.

Best of luck for v0.12!

@ghost
Copy link

ghost commented Mar 31, 2020

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.

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants