#terraform-tool

^7heo: one of the GH attack vectors is quite interesting: http://insight-labs.org/?p=1682

phrawzty: thanks for the link.

phrawzty: it's quite interesting.

is it possible to parse shell variables via terraform?

(without using the local or remote exec hoohks)

(hooks*)

phinze: is it possible to have a list of strings as a default value in a schema attribute?

^7heo: as i said earlier in that thread, that kind of feature is dangerous

Spark: I read that you said it's dangerous, not why.

Spark: did I miss something?

it's a long thread, but basically you end up losing hermiticity

and having a configuration that is not easily replayable

that can be a major pain e.g. when transferring from one engineer to another

when someone leaves the company or gets hit by a bus

in principle it's ok to use the environment, but it has to be really explicit that you're doing it, and not buried 3 modules deep in the middle of a userData field

Spark: I don't get it, isn't it possible to leave the values as shell variables in the config?

whcih is why i suggested limiting it to tfvars and the commandline

aka only subsitued during execution

yeah but it soudns like you're proposing a general ${shell} interpolation syntax, which is not that

Spark: I am proposing the syntax for it to fit the existing one.

Spark: I'm not saying anything should be saved AFTER interpretation to the tfstate

it's not about the tfstate

it's about the tf

all of this stuff is gone by tfstate i'm pretty sure

then I don't get it... how can it be harmful in the tf?

because it's configuration as code

you don't it to be non-determinsitic

I mean, yeah, sure, if people do weird ass shit with it, it can be anything

or change behavior unexpectedly

now, if you're clever enough to use shell.env.USER

for example

that'll work everywhere.

it's pointless to want to protect people against their own stupidity.

even that is a bad idea tbh