#terraform-0_12 (2019-05)
Discuss upgrading to terraform 0.12
Archive: https://archive.sweetops.com/terraform-0_12/
2019-05-09
Almost there!
2019-05-22
i know they really tried to focus on making the 0.11 -> 0.12 migration easy (even providing a migration tool), but im curious to see how much of a headache (or lack thereof) it will be
Has anyone done his yet for a sizable terraform codebase?
here’s a reasonably sized project that just converted for tf 0.12 compatibility, https://github.com/nozaq/terraform-aws-secure-baseline/pull/38/files
(I guess I’m more interested in a non-monorepo migration)
…though this is a great case for mono-repo
I’d expect similar types of updates, plus a little workflow around versioning… Pin references to nested modules (which you should be doing anyway), update leaf modules, release those updates as new versions, update parent modules once all nested/leaf modules are good
For sure it’ll suck more if you feel the need to backport patches to support two major versions at once
(basically, we have 130+ repos… so it’s gonna hurt. a lot and we don’t have a graph of how they are related, so planning it out is difficult)
nope, kinda worried to
even now some of the providers i use are pretty fickle (when using them together - azure, kubernetes, helm, etc)
but it was a relatively simple thing
all our datadog monitors
for all our customers
so 20~ modules used about 40 times each, with about 3 or 4 resources per module. The most time consuming part was upgrading the modules, docs and publishing new versions etc.
2019-05-23
- vpc.label in .terraform/modules/vpc.label
There are some problems with the configuration, described below.
The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.
Error: Attribute name required
on .terraform/modules/dynamic_subnets/private.tf line 34, in resource "aws_subnet" "private":
34: ignore_changes = ["tags.%", "tags.kubernetes", "tags.SubnetType"]
Dot must be followed by attribute name.
Error: Attribute name required
on .terraform/modules/dynamic_subnets/public.tf line 35, in resource "aws_subnet" "public":
35: ignore_changes = ["tags.%", "tags.kubernetes", "tags.SubnetType"]
Dot must be followed by attribute name.
ah
This is from the https://github.com/cloudposse/terraform-aws-dynamic-subnets module.
Is there any roadmap for making the module 0.12 compatible? Let me know if I can be of help somehow.
We will inevitably support 0.12, but not until there’s more mainstream adoption.
Most likely it will come from (cloudposse) customer demand.
I think we might need to start with a master/0.12 branch and go from there.
also, it will mess with versions. We’ll probably need to affix +0.12 to the semmver
e.g. 0.1.2+0.12
and doubt we’ll be backporting fixes.
Allright, thanks for the info.
Welcome suggestions from community on how we can straddle the two worlds.
And if the proposal above make sense.
2019-05-24
found a bug in matchkeys, https://github.com/hashicorp/terraform/issues/21432
looks like they might have just run the upgrade tool on everything?
2019-05-25
2019-05-26
2019-05-28
hey, a little question regarding 0.12, seems the feature of generating resources based on count and value list still keeps resources list in statefile in an indexed structure, is there a workaround? Still can’t remove an element from anywhere but the end of the list without forcing a replace on remaining elements.
That’s still a limitation in this release… They’ve indicated it will be addressed in 0.12.x, but no indication of what value of x… (Other than not 0)
aww, sucks, but thank you
I think it is a good idea to read the whole Terraform docs, because there are few things here and there. Attrs as blocks is one of the most trickiest
yeah, i’m not a fan of that change. makes it impossible for many resources to write modules that work for both tf 0.11 and tf 0.12
hah, is there even a point to try and make them compatible?
i wanted an upgrade path of this kind:
- update modules to be cross-compatible as a patch release
- update the executing project to use tf 0.12
- leisurely update modules to leverage tf 0.12 syntax
1 is fast, easy, and low risk
and gives users an inflection point for their own upgrade paths. hashicorp is doing the same thing for providers with their SDK and with tf 0.11.14
I think adding version tags in your modules is the supported approach. Honestly this upgrade is going to be long enough and slow enough I suspect branches or forks will end up having to be the real world answer.
2019-05-29
Doesn’t look like that module has too many….hairy parts…..the rest of us have been using hacks on hacks on hacks
2019-05-30
any handy 0.12 cheatsheets?