I have lists of security groups and or lists of ec2 instances that i would like to to keep in arrays ( separated by files which are auto loaded by *.tf ) so i know when i change things in one place, it gets changed in another.
Right now vars can only hold strings or key value maps, but not arrays (if i am reading the docs and error messages correctly)
This is something that will help maintaining a clearer terraform-maintained infrastructure. :+1:
How would be the load map for this enhancement? For example planed for 0.4?
:+1:
:+1:
:+1:
:+1:
:+1: + same for maps
:+1:
:+1:, y'all
I would like to be able to do this:
variable "all_zones" {
default = {
us-east-1 = [
"us-east-1a",
"us-east-1b",
"us-east-1d"
]
us-west-1 = [
"us-west-1b",
"us-west-1c"
]
}
+1. Looks like this is done already and slated for release in 0.4.0 Nice!
btw: the way you guys maintain your changelog.md is down right inspiring and incredibly useful.
You don't see that often enough in the open source world--props!
@joegoggins Not completely fixed but there is certainly a workaround in 0.4.0.
And thanks for the compliments on the changelog! :)
What's the status of this? My use case is the same as the OP's. I don't see mention of this in the 0.4.0 release notes...
Split/join is the workaround for now I take it?
Yes, for now.
:+1: and then we will need to be able to do something like:
cidr_blocks = ${var.ip1} + ${var.ip2} + ["0.0.0.0/0"]
Is someone currently at work on this? I'm willing to jump in and start a patch if not.
I'm not able to get the split
/join
hack working for aws_instance.security_groups
. I've got a module configured this way:
# foo.tf
resource "aws_instance" "server" {
...
security_groups = "${split(",", var.sec_groups)}"
}
# variables.tf
variable "sec_groups" {
default = "sg-xx,sg-x,sg-xxx"
description = "The security groups to instantiate the EC2 instance under."
}
and using it thusly
# foo_user.tf
module "foo" {
sec_groups = "sg-x,sg-xx,sg-xxx,sg-xxxx"
}
and getting this error:
⇨ terraform plan -var "access_key=$KEY" -var "secret_key=$SECRET" -module-depth=1
There are warnings and/or errors related to your configuration. Please
fix these before continuing.
Errors:
* aws_instance.server: security_groups: should be a list
Any insight?
I think you need to wrap your usage of split with [ ].
So
security_groups = ["${split(",", var.sec_groups)}"]
Thanks, @johnrengelman. Two things:
Um. Not sure. Did that work for you?
Sorry I'm only on my phone right now.
Yeah, it did. Been pouring over the docs for the better part of the day and didn't see that anywhere...
Wow, that's nuts.
Agree with you here, I made the same mistake the other day, but I'm afraid this is all coming from the fact that there's no direct support for arrays yet. It's all internally stored in a string so far.
Is this in the docs anywhere?
Interpolations are generally documented here, I can't think of any specific place that would be mentioning this behaviour though, feel free to chime in with PR to docs.
Yeah I think that's just one of those things about indicating that it's an array. I ran into that earlier this week.
feel free to chime in with PR to docs.
unless @mitchellh and/or the core team plans to work on the array support for the next release, but AFAIK it's not currently the top priority on the list. // please correct me if I'm wrong
@jamesob it's documented in the sense that certain Attributes of specific resources require a list
input, and using .split()
is a "workaround" to generate a string inside the list
that matches HCL's list formatting.
You need to reference specific resource attribute documentation to determine if the correct input needs to be a list or not, e.g. http://www.terraform.io/docs/providers/aws/r/db_parameter_group.html#parameter or http://www.terraform.io/docs/providers/aws/r/route_table.html#propogating_vgws are lists
@solarce nowhere is it documented that you use an unintuitive notation to signal that a string is "actually" a list by way of some interpolation function, i.e. ["${split(",",var.foo)}"]
. This is a bug.
I'll be submitting a doc PR in the next few minutes in the module
section, detailing
@jamesob it's not limited to modules, even when you're declaring actual resources directly in your configuration file, some inputs to attributes need to be a list and use [ "item1" ]
syntax , even if it's just a list of one item.
The entire point of using split and join is working around the fact that right now a string is the only thing that can only be assigned to a variable.
Previously all you could do was define a static list using multiple variables, like in https://github.com/terraform-community-modules/tf_aws_asg/blob/master/main.tf#L47
@jamesob I think what is happening here is that when you initially declare the split
it's inside a string interpolation. So from the perspective of the code that's parsing the parameters, there is a String there. So you need to wrap the string in []
to make it a list. The interpolation must be happening later which breaks the single string into multiple.
has there been any progress on this? I just had an issue with the join/split workaround: https://github.com/hashicorp/terraform/issues/1997
@c4milo I'm taking a look at this today. Golang newbie here though, so no promises :).
+1 This would be a big help!
:+1:
:+1:
+1
:+1: Would help massively
It's been a year... is this going to happen?
I'm waiting here for advice/a second pair of eyes: https://github.com/hashicorp/terraform/pull/2697
:+1:
Would love this solved!
Would be very useful in making code clearer :+1:
:+1:
:+1:
+1
:+1:
:+1:
:thumbsup:
+1 This one and nested array/maps are most missing features
:+1:
+1
:+1:
+1
+1
:+1:
:+1:
This is actively being worked on at the moment - in due course changes will appear in hashicorp/hil
and then in this repository,
:+1:
:+1:
:fireworks:
-- sent on the fly
On Feb 15, 2016, at 9:46 PM, James Nugent [email protected] wrote:
This is actively being worked on at the moment - in due course changes will appear in hashicorp/hil and then in this repository,
—
Reply to this email directly or view it on GitHub.
:+1:
:+1:
:+1:
:+1:
+1
+1
:+1:
+1
Hey guys ; it's official ; we can now stop adding :+1: to this thread
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments
In an attempt to challenge folks' idea that +1 comments are useless (to anyone), I'd like to share my reason for using it:
I'm subscribed to many issues across many repos.
Within a repo, I'd like to be able to search issues by notifications:subscribed
. But that feature doesn't exist. Boo.
If the new reactions feature could help me search for issues I care about, I'd use that, but since it doesn't, I'll be continuing to post +1 comments so I can use commenter:$USERNAME
as a proxy for "find issues that I'm subscribed to".
If y'all have a better system, I'm all ears.
Yeah, that's why I +1 also :)
DIE EMOJI!
On Fri, Mar 11, 2016 at 11:56 AM, Marc Tamsky [email protected]
wrote:
In an attempt to challenge folks' idea that +1 comments are useless (to
anyone), I'd like to share my reason for using it:I'm subscribed to many issues across many repos.
Within a repo, I'd like to be able to search issues by
notifications:subscribed. But that feature doesn't exist. Boo.If the new reactions feature could help me search for issues I care about,
I'd use that, but since it doesn't, I'll be continuing to post +1 comments
so I can use commenter:$USERNAME as a proxy for "find issues that I'm
subscribed to".—
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/issues/57#issuecomment-195452145.
This has been open for a year, everybody wants it, any status?
Most the work to support this is merged already for 0.7. I expect a close is imminent.
Eta?
Soon. Watch CHANGELOG.md - 0.7 changes are already being updated.
On May 16, 2016, at 11:23, Franklin Wise [email protected] wrote:
Eta?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
Hi all
I am going to close this - all of the initial work for lists has been merged. There are a few outstanding issues being tracked but there are open issues for these
Paul
Where is the best place to track this enhancement moving forward?
@baler 0.7 will allow lists in variables
could you provde an example of how to pass list in variable? I am still getting an error when passing a list of instances to an ELB module.
error
variable instances in module solrs_elb should be type string, got list
module
module "solrs_elb" {
source = "../../modules/Generic/mod_elb_slrs"
environment = "${var.environment}"
application = "${var.application}"
slrs_elb_sg = "${module.ci_solrs_elb_sg.SLRS_ELB_SG_ID}"
subnet_AZa = "${var.slrs_elb_subnet_private1}"
subnet_AZb = "${var.slrs_elb_subnet_private2}"
instances = ["${aws_instance.CI03T02QSLRS.0.id}","${aws_instance.CI03T02QSLRS.1.id}"]
}
elb resource
resource "aws_elb" "ELB-SLRS" {
name = "ELB-${var.environment}-SLRS"
internal = true
subnets = ["${var.subnet_AZa}", "${var.subnet_AZb}"]
security_groups = ["${var.slrs_elb_sg}"]
listener {
instance_port = 8080
instance_protocol = "http"
lb_port = 8080
lb_protocol = "http"
}
health_check {
healthy_threshold = 10
unhealthy_threshold = 2
timeout = 5
target = "TCP:8080"
interval = 30
}
instances = ["${var.instances}"]
cross_zone_load_balancing = true
idle_timeout = 60
connection_draining = true
connection_draining_timeout = 400
tags {
Name = "ELB-${var.environment}-SLRS"
Application = "${var.application}"
Environment = "${var.environment}"
Balancing = "SOLRSlave"
}
}
@davyt10 inside your module you declare something like variable instances {}
. Trying changing that to be:
variable instances {
type = "list"
}
worked..thankyou!
Most helpful comment
Hey guys ; it's official ; we can now stop adding :+1: to this thread
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments