#terraform-0_12 (2019-06)

please someone tell me what i am doing worng

and i am getting back

seems like it founr the right subent id but ignores it

when i remove the module.main.web_public_subnets[0].id and hard code the subnet it works

and this happens also if i make module.main.web_public_subnets output to be only one var and then remove the [0]

never mind i added .id but forgot that i took the value from an output and not the resource output

https://github.com/cloudposse/build-harness/pull/152

it’s dirty. it’s nasty. but if you need terraform-docs to work with 0.12, it works for us.

@antonbabenko

Awesome! Thanks @Erik Osterman (Cloud Posse)!

A small appreciation to hands down one of the best modules out there

module "label" {
  source    = "git::<https://github.com/cloudposse/terraform-null-label.git?ref=0.12.0>"
  stage     = local.stage
  name      = local.name
  delimiter = "-"
  tags = {
    "kubernetes.io/cluster/${module.label.id}" = "shared"
  }
}

Not sure if this will work in 0.11 though.

thanks @Nikola Velkovski!! comments like these is what keeps us going!

and the salary….and food too

And the coffee

@Erik Osterman (Cloud Posse) what is the problem with the current terraform-terraform-label pr for 0.12.. I’d ike to push dynamodb to 0.12. Also current travis config fails for 0.12 still if im not mistaken.

@Andriy Knysh (Cloud Posse) started working on it but had to take some days off

We need to take a few steps with each module

First updating it to use Codefresh where we have all the 0.12 tooling in place

I will try to rush this out though for you if it’s a blocker

Hi,

I just started to upgrade the gilab-runner-spot-module (for AWS) to TF 0.12. Would be great if you can help me with the following questions.

I used the tool terraform-docs to generate documentation of the variables, this tool seems not working (yet) for 0.12. Does anybody knows / uses an alternative approach?

Does anybody has a tip what is the best way to upgrade a data “aws_ami”. In my TF 0.11 module I had provided the option to inject the filter via a variable as follow:

variable "ami_filter" {
  type        = "list"

  default = [{
    name   = "name"
    values = ["amzn-ami-hvm-2018.03*-x86_64-ebs"]
  }]
}

data "aws_ami" "runner" {
  most_recent = "true"

  filter = "${var.ami_filter}"

  owners = ["${var.ami_owners}"]
}

Does anybody has a good example how I can keep the filter(s) configurable in tf 0.12?

Oops, already hab an answer on the filter question, map with a dynamic block

Is it possible to taint an entire module yet?

hi all, seems like terraform-null-label is not compatible with terraform 0.12. The same module being used in all modules make them kind of unusable too

starting from https://github.com/cloudposse/terraform-null-label/releases/tag/0.12.0, it does support TF 0.12

https://github.com/cloudposse/terraform-null-label/releases

to use it with TF 0.12, pin to the latest release

to use with TF 0.11, pin to 0.11.1

then we have to change this in all the modules correct, i can send pr for the modules which we uses.

we have to update all the modules, we are working on it now

PRs are welcome, thanks

or may be a better solution is https://dependabot.com/terraform/

which should fix this across all repos for you

have you tried that?

we are using dependabot

not sure if it’s possible to automatically convert everything to TF 0.12

works in simple cases

but usually you have to manually fix/update the code after the conversion

as far as I’ve seen it, the automatic conversion can’t work in some cases or breaks code in other cases

i though you only need to update the null-label dependency across all projects.

if your modules are TF 0.11 and you point them to null-label 0.12, will it work?

i didn’t tried null-label 0.12 yet. What I do know is you can make null-label 0.12 work with both 0.11 and 0.12.

If its not working for any particular syntaxes, should raise a bug in terraform

anyways you can specify that modules with tag version like 2.x only support 0.12

that’s what we do https://github.com/cloudposse/terraform-null-label/blob/master/terraform.tf

will not work with TF 0.11

if your modules are TF 0.11

i got it, you are saying automated null-label bump is not satisfactory since you want to address tagging along with it.

anyways I will send pr for the modules which we are using.

i mean when you update your modules to TF 0.12 and if the modules use the label, you will bump the label version in the new TF 0.12 code

automated label bump to TF 0.12 in the module that supports only 0.11will not work

that i agree, but if we fixed the deps and ci runs auto terraform 0.12upgrade --yes we can easily check narrow down the errors. Few modules like https://github.com/cloudposse/terraform-aws-key-pair.git don’t need anything apart from label bump and upgrade.

anyways there is a faster way which is clone all repos and do sed to replace version.

so automation won’t be worth it

Dependabot is awesome but without automated tests, a sure fire way to absolutely break everything with regressions

We tried it on a handful of repos about a year ago and quickly things started breaking (aka GitHub issues started spiking)

So as part of our upgrading to 0.12 we are trying to add more tests with terratest and bats

That way we catch regressions or at least have a way to test for them as they arise in the future

yup ci should have better tests for automations

But with 100+ modules we should work in that direction as well. I would love to help with something you required.

one more thing I would recommend is to have version.tf file. The automatic upgrade does create this file and its easy to identify current terraform version for modules by just looking at the presence of file.

@rohit.verma would massively appreciate some help

I will type up some guidance

today i sleep, tomorrow morning I would try an approach to bump all those modules which requires lesser tinkering with some scripts.

If you have time to do a quick call this week that would be awesome too

Ok

the part where i got lazy is fork and raise pr

You were working with some in house git bots, right?

yes but they are mostly chatops related thing, and work within an org

Did you finish rolling out test-infra used by istio?

And k8s

no but we did the vanilla prows one and hooked with tekton

you can avoid tekton and can continue use cloudfresh in parallel

Btw office hours today at 11:30 - in 1.5 hours

i got severe cold, and its already past 10 pm for me

Oh no! Definitely get some rest

early morning person, i probably won’t be able to attend any of your office hours till I am in bangalore.

Will catchup tomorrow morning with what I was able to do.

Also you need some marking strategy whether the repo is done, may be presence of version.tf or a specific tag versioning method

I would recommend version.tf

If you agree can we add that to null label repo

sure

we added it to the examples https://github.com/cloudposse/terraform-null-label/blob/master/examples/complete/versions.tf, which get tested automatically

That label module is the hotness

hey folks - if you were starting a new project, thoughts on using 0.12 from the get go….? cc @antonbabenko @Erik Osterman (Cloud Posse) @Andriy Knysh (Cloud Posse)

should be ok. Not sure about it 100% since we converted just a few modules, working on the rest now

Nice, any “fun” with lists of maps/other workarounds we came up with for enabled/disabed etc?

(we did not get to those modules yet)

but a lot of fun with expressions like this https://github.com/cloudposse/terraform-null-label/blob/master/main.tf#L40

hah, I bet

Cheers Andriy

0.12 is definitely more enjoyable

I would start fresh with that

are many of you guys running into:

Error: Failed to instantiate provider "aws" to obtain schema: Incompatible API version with plugin. Plugin version: 4, Client versions: [5]

I get this with 0.12.2.

the solutions I seem to find out there are to recompile tf, but wondered if people had a workaround?

What version of the aws provider are you using?

huh, I guess

  version             = "~> 2.16"

works

Ahh, they must have updated the schema version?

https://github.com/orgs/cloudposse/projects/13

why have terraform-terraform-label and terraform-null-label. Are we planning to deprecate anyone?

terraform-terraform-label was introduced as a simpler alternative to terraform-null-label which grew unwieldy in 0.11

with 0.12, terraform-null-label is once again sane, but we’ll continue supporting terraform-terraform-label

and both have been updated to 0.12

Thanks @Erik Osterman (Cloud Posse)