#terraform (2020-12)

Is that inside a template or something?

it is being passed directly to the module as value to environment

(fwiw, value = "${var.spring_active_profile}" is HCLv1 syntax. In HCL2, it should be value = var.spring_active_profile )

Is that extract taken from a tfvars file?

It is not

It is being passed directly to the module

Can you share a minimal example?

Here’s an example using the terragrunt style

Ah terragrunt.

Yes, it’s not possible to do that, since terragrunt is a wrapper and is just setting these inputs as TF_VAR_… when calling Terraform.

The way I understand the purpose of terragrunt.hcl is that it is where you set the variable values.

Can you explain why you need to do it this way?

the values get passed in via a regular terraform module

that was just an example

I’d need to see the entire example with all files

Consider the #terragrunt channel instead

Do you have sample codes I can try locally?

https://github.com/cloudposse/terraform-aws-elasticsearch

You can validate that the value is a number 0-5. I don’t think you can enforce a number that is not the default if and only if some other variable is some value

You could use a conditional in your terraform code that changes the value if the other value is true

You would in effect be setting a different default when the other value is true

You can’t do it with validation, as that can only reference the variable in question.

There is another way to do this, but it’s a little weird. I personally use it heavily because I think it’s really useful to enforce conditions like this rather than let them generate hard to understand errors.

data external validate_replicas {
  count = var.cluster_mode_enabled && var.replicas > 5 ? 1 : 0
  command = [ "Error: if cluster mode is enabled, replicas must be 5 or less." ]
}

i believe the expression syntax using parens may work?

("terraform:managed") = string
("terraform:root")    = string

Thanks Loren, not working on my quick test. Did I misunderstand?

variable "configs" {
  description = "TESTING of configs."
type = object ({
      ("terraform:managed") = string
      ("terraform:root")    = string
    })
}

Also just trying changing the “(“ to “{“ {“terraform:managed”} = string {“terraform:root”} = string

but no joy

i wasn’t certain it would work in a variable definition. the syntax works elsewhere in tf where the expression confuses the standard parser. wrap the expression in parens and the parser then knows what to do. but the colon may confuse it further, since both colon and equal are valid separator tokens for tf maps

Fair enough, and thank you. Just wanted to double check I’d not simply applied your suggestion wrongly. I can work around it for now, it was only a name of a AWS tag, so can injected it in later, was just trying to get as much into my data structure as possible.

for example, this works:

$ cat main.tf
locals {
  foo = {
    ("colon:test") = "bar"
  }
}

output foo {
  value = local.foo
}

$ terraform apply

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

foo = {
  "colon:test" = "bar"
}

though, as a local like that, the parens are not needed around the key

Ah, that’s good to know. (you should share a get me a beer/coffee link) I think I owe you many now.

haha, all good

might want to open an issue with this use case. the locals test shows that the colon is valid in the key. i think this means that the object constructor is not quite intelligent enough to handle this correctly

Good point, I’ll get one written up when I get home.

only related issue i can find is this one, indicating the same problem with a period in the key… https://github.com/hashicorp/terraform/issues/22681

Thanks for the reference, I’m happy to try and report it. I’ve a few hours travel until home so will do it once I get there.

right, so that mean you also comment out of the terraform cloud source while doing local development?

yes. That’s what I do when testing changes to any module locally

hmm are you trying to use a docker volume or mount a volume from another container?

I want to use docker volume which can act as a fresh volume for this newly created container. Actually my use case is that I want to use a volume which is shared between host and container. I want to access files placed on a specific path inside the container from host.

Ah yeah so you should define your docker volume parameters in the task definition then use the same volume name in the container definition

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_task_definition

if you look at the example under docker volume configurations you’ll see how the docker volume is reference, in your container definition using the cloud posse module you would just use sourceVolume to reference the name defined under volume.

So I’ll put

  volume {
    name      = "service-storage"
    host_path = "/ecs/service-storage"
  }

inside task definition and inside my container definition module I’ll use

  volumes_from = [
    {
      sourceContainer="service-storage"
      readOnly=false
    }
  ]

~yeah something like that!~ sorry not volumes_from you’ll need mount_points

Got it. I overlooked task definition, My bad. Thanks @Tom Dugan

Got it.

Yep.

any specific one you’d recommend?

i essentially need to do the following …

-- Create required databases
CREATE DATABASE notaryserver;
CREATE DATABASE notarysigner;
CREATE DATABASE registry ENCODING 'UTF8';
-- Create harbor user
-- The helm chart limits us to a single user for all databases
CREATE USER harbor;
ALTER USER harbor WITH ENCRYPTED PASSWORD 'change-this-password';
-- Grant the user access to the DBs
GRANT ALL PRIVILEGES ON DATABASE notaryserver TO harbor;
GRANT ALL PRIVILEGES ON DATABASE notarysigner TO harbor;
GRANT ALL PRIVILEGES ON DATABASE registry TO harbor;

There is a terraform-providers/postgresql provider which is the standard AFAIK.

from what i saw it doesn’t handle user creation

Ah maybe you’re correct on that front. I’ve created roles through the psql provider but not users probably.

makes sense

You can create a login role with the postgres provider which should be what you want, afaik

this didn’t seem to work for me

i am getting the following error …

no but I am doing something similar with snowflake using https://tf-registry.herokuapp.com/providers/chanzuckerberg/snowflake/latest very positive experience

nice i am looking for something that’ll work with AWS RDS

I use…….

mysql = {
      source = "terraform-providers/mysql"
    }

Just don’t try and manage users from the same Terraform configuration you create the rds resources

why?

( I do……what did I do wrong?)

The provider needs to be configured before resources are created. If you attempt to configure the db provider based on the dynamic hostname/credentials generated in the same Terraform stack this is impossible

It works if you create the cluster first and later add the db provider resources. But it will fail if you ever rebuild the stack

Even worse, the MySQL provider has silent defaults for credentials. If you try and load them from a non-static source, it will appear to work but really be using localhost for the hostname or whatever

I was planning to have a module that wrapped my existing rds module and then took the outputs from that and passed them to the provider. Are you advising against this?

Yes, exactly

Personally I break it up into two configurations. First configuration creates rds, second manages users and other objects within.

But other people keep it in a single configuration and use hardcoded variables plus apply -target runs. Both work.

That’s going to be difficult for us as we want to provision the DB when it’s created

in TF you can search the cluster and then run the user creation and grant

It’s not that difficult. Your repo has two terraform configurations. create-rds/main.tf and everything-else/main.tf. Run terraform apply twice in a row

ahhhhhhh ok , that is another way

I’ve enjoyed using the new concise diff engine.

same here, I will wait for few updates

I’m interested in others responses as well . I have some of my own opinions and I’ll share some resources on the topic that have helped our organization develop our TF code structure. I would assume you are not using Terraform Cloud?

• Terraform Repository Best Practices

• Terraform for Production

• TF Vars Driven method

• Digital Ocean’s Take on Directory structure On the topic of Terragrunt, I do not personal use it but colleagues of mine do use it successfully. The feedback is mostly positive. I will say that Terragrunt does abstract some vanilla Terraform features that has resulted in some miscommunication of concepts between us

Correct. I am not using TF cloud.

Thanks @Tom Dugan. I’ll look into the material. I personally want to avoid Terragrunt

I am interested in what you end up with!

Sure. I’ll share.

I use modules (local and published, a “base” folder that holds common configuration across environments. Then for each environment I just symlink to the common stuff in the “base” folder. In each specific environment I’ll use separate tfvars files to set the modules settings for each env. Works fine for me. Just another idea for you.

Also, an “Environment” might be represented by 10s or hundreds of workspaces. It’s never just 1 giant workspace with everything in there.

Here’s a small example:

├── Makefile
├── README.md
├── modules
│   └── default_route_device
│       ├── main.tf
│       └── variables.tf
└── projects
    ├── account-base
    │   ├── account-base-nonprod.auto.tfvars
    │   ├── account-base-prod.auto.tfvars
    │   ├── account-base.auto.tfvars
    │   ├── datasources.tf
    │   ├── main.tf
    │   ├── providers.tf
    │   ├── template.sh
    │   └── variables.tf
    ├── blah-env-us-east-1
    │   ├── account-base-nonprod.auto.tfvars -> ../account-base/account-base-nonprod.auto.tfvars
    │   ├── account-base.auto.tfvars -> ../account-base/account-base.auto.tfvars
    │   ├── backend.tf
    │   ├── datasources.tf -> ../account-base/datasources.tf
    │   ├── main.tf -> ../account-base/main.tf
    │   ├── providers.tf -> ../account-base/providers.tf
    │   ├── blah-nonprod-us-east-1.auto.tfvars
    │   └── variables.tf -> ../account-base/variables.tf
    └── blah-env-us-west-2
        ├── account-base-nonprod.auto.tfvars -> ../account-base/account-base-nonprod.auto.tfvars
        ├── account-base.auto.tfvars -> ../account-base/account-base.auto.tfvars
        ├── backend.tf
        ├── datasources.tf -> ../account-base/datasources.tf
        ├── main.tf -> ../account-base/main.tf
        ├── providers.tf -> ../account-base/providers.tf
        ├── blah-nonprod-us-west-2.auto.tfvars
        └── variables.tf -> ../account-base/variables.tf

Thanks @Jonathan Le I’ll be taking a look into the shared approach while working on finalizing the approach that suits my organization.

NP. your requirements might be different than mine, so just giving an example of think about. Good luck.

This works just fine but as you can see, a portion of my path is something that can be programmtically filled in. I was thinking of using a local variable called prefix then that would cut down on having to type out the full path each time.

I was hoping I could do something like for_each for the parameter_write = part?

Maybe something like this? I’m trying to find more information on how this is achieved.

dynamic "parameter" {
  for_each = [for param in properties: {
    name = "${local.prefix}-${param.name}"
    value = param.value
    type = param.type
    overwrite = param.overwrite
  }]
}

I also noticed that the module is currently using count instead of for_each so at this time I’m not sure if it would introduce any problems.

I don’t personally use this module but I would echo the last concern about it using count vs for_each in that case I would opt to for_each the module if i were to use it. Saying that I just for_each the parameter store resource itself and I do define a path as a local.

Ya, we’d accept PRs to update the module to use for_each - just nothing we got around to.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-cloud-watch-events.html#rds-cloudwatch-events.sending-to-cloudwatch-events

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html

@Steve Wade (swade1987) try above

thanks man appreciated

i am currently fighting python code at the moment

Check out terraformer

https://github.com/GoogleCloudPlatform/terraformer

https://twitter.com/Gowiem/status/1329486486685642754/photo/1

(this is fully a joke, don’t do that)

Thx Matt!

I’d keep it separate… You can use a source-only module to retrieve the go project, and reference paths in .terraform to pass to your tf lambda resource

The go project doesn’t need any tf code at all

note the link between the label of the source-only module, foo, and the path .terraform/modules/foo/...

You’ve lost me, I can reference a zip file from a source code url?

i don’t know why you would create the zip. let the module do it

What am I passing to the module then just the binary itself?

recommend reviewing the module readme

Interesting I’m using a different module at the moment can easily switch though

i don’t see any examples in the repo for golang, so it will involve some experimentation to figure out how to get the module to build it. or you have your golang devs build it as part of their release/version cycle, and you can pull down that artifact and have the module create the zip of it

I think the easiest option would be to release a zip file as part of the golang repo and reference it that way

It’s so trivial to do I just need to work out how to get in inside tf

i just so despise committing a zip file or any binary to a repo. makes me sick inside

Not commiting having it as a release artifact

oh right

that makes sense, your golang pipeline can compile the code and create the zip at the same time. easy

Exactly

Then I’ll use a null resource to get it

i guess now you can instead publish a container with the package, instead?

might be even easier

https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/

The issue with that is from the looks of things it has to be an ECR image

sure, either way, you’ll need to publish the release artifact to somewhere… i guess as part of your tf config you could somehow mirror from another registry to ecr. or just push from the golang pipeline to ecr

Neat trick. Never had a reason to come up with the thought to use files from .terraform yet. For the very small lambda stuff so far, the .go file just sits next to the terraform files. Will keep this method in mind for future

it’s a new favorite pattern of mine. helps separate concerns across different teams and projects. takes advantage of how terraform init pulls all module sources to the local .terraform cache before generating the plan. so the files are guaranteed to be at that path

@mfridh do you create the zip file as part of the terraform code or is that in the module directory already?

@Alex Jurkiewicz thanks!

is this required in 0.14? for some reason I think this was going to be required at some point

I think it might be

another quick question, so doing the above to a sub module appears to actually initizalize a provider instead of using the root one, i know in tf 0.12 this could cause problems when removing resources or the provider itself, from the module. but is it generally okay now

├── provider[registry.terraform.io/hashicorp/aws] 3.16.0 ├── module.vpc │ └── provider[registry.terraform.io/hashicorp/aws]

each module would have its own aws provider

its just before we were initalizing providers in each module, then trying to remove the module caused errors, if it had a seperate aws provider in the module, i just wanna make sure im not making the same mistake

I’m not really sure what the behaviour here is in theory, but in practice you “shouldn’t” run into problems. You should create all providers at the root level and pass them to your modules, rather than relying on the modules creating them.

kk thanks again man

provider "aws" {}
module "rds-cluster" {}

will implicitly use the root aws provider

provider "aws" { alias = "aws1" }
provider "aws" { alias = "aws2" }
module "rds-cluster" {
  providers = {
    aws = provider.aws2
  }
}

will explicitly pass a specified provider (the syntax is off the top of my head, check the docs for correct details)

will still use the root provider, even tho i put the required_providers in the terraform block of rds-cluster right?

i think i got it tho

it makes sense

thanks for all the help man

modules will create providers if one doesn’t exist that’s suitable in the root configuration. IMO this is bad, but it’s the way Terraform works. So just make sure to create the providers yourself and you won’t get surprised

this worked, doing a local init outside of tfe, was able to correctly udpate these providers

thanks man

no prob!

Thanks @Jurgen - you beat us to it.

Let’s use #pr-reviews, but we’re standing by to help review.

ah, didn’t know the channel.. i’ll move

yeah, I just have a project that isn’t in prod yet and I am beating the fore front of all versions

so not afraid to have shit break on tf betas, etc.

I’ve never seen cloudformation do updates better. But I have used cloudformation when tf didn’t yet support the resource but cfn did

yes i use the aws_cloudformation_stack but only because our 3rd party CICD tool provides that instead of a terraform module

I used it for autoscaling group rolling updates.

Primarily when EKS Managed group wasn’t introduced yet.

No info for ya, but I’m interested in following along on this one. I’d like to roll out TFLint to a large client Terraform monorepo at some point soon.

What are you hoping for it to catch for you?

I’d just like to enforce more consistency before folks commit. I’ve got other infra engineers who follow the patterns I’ve put in place, but there are a ton of more dev focused folks on the team who are writing TF code now so I’d love to catch naming, quoting, and other linting style hiccups before their code gets into PR and I have to reject it.

Ah, TFLint can definitely do that for you. It is also capable of handling lint issues on a per provider basis - like look for specific errors people tend to make with the AWS provider.

Yeah, figured as much. Just need to implement it! Following along on threads as I’m interesting hearing if anyone ways in with good tips for you

Most probably you came across that already https://github.com/antonbabenko/pre-commit-terraform

Yep

Are you looking for the tools or the policies?

There’s conftest which speaks rego, but haven’t found a catalog of policies yet.

https://github.com/Blokje5/validating-terraform-with-conftest

The policies Then I can try and figure out what tools cover them, or not.

I’m trying to start from “what are the policies and rules worth having”, and then see what I can use to enforce them.

Ya, it’s the hard part for sure. We’re creating catalogs for this kind of stuff (we have for SCP, AWS Config, Datadog, etc). Nothing yet for HCL policies.

Checkov perhaps?

That’s more of a security analysis than an operational analysis, no?

You can create “cost policies” using checkov if you mean that by operations.

like ec2 types etc

Lifecycle: Retain [Add ‘retain’ attribute to the Terraform lifecycle meta-parameter]
Issue//github.com/hashicorp/terraform-provider-aws/issues/902)
Some resources (e.g. log groups) are intended to be created but never destroyed. Terraform currently does not have a lifecycle attribute for retaining such resources. We are curious as to whether or not retaining resources is a workflow that meets the needs of our community Huh what would that do …. you run a destroy but it leaves that particular resource (and dependencies) alone and ‘dangling’ within AWS?

that’s the idea yeah

That could be pretty useful is you were trying to have your environments scale to zero.

What does ‘scale to zero’ mean?

Oh, kubernetes thing

Scale to zero is the idea that you don’t have running infra costs when no one is using it. So lambdas are a good example. But let’s say you’re running a Fargate cluster, you could scale your instances and any other bill-per-usage infra down to zero overnight for example and not have to pay for them.

Sure. How’s that play into this idea of resources left outside the state?

The retain functionality would be less helpful with actually scaling your compute cause that already has good scaling functionality, but could help with removing your elasticsearch cluster but not your VPC for example.

Ah

for the duplicates, are the key and value both the same?

Is it

{
  "foo" = "bar"
  "foo" = "bar"
}

or

{
  "foo" = "bar"
  "foo" = "baz"
}

Also, it may be possible to have a map with duplicate keys, but that is not the intention of map. Maps are supposed to be lookup tables of unique keys to values

oh hang on I see what you are saying. The keys are different but there are duplicate values

In the case of having duplicate values, how are you deciding which key to keep? The first instance? Or some other logic

Afternoon Andrew, the data set I have would be the second option

{
  "foo" = "bar"
  "foo" = "baz"
}

Is it? I’m understanding your question now as you having this kind of data:

{
  "foo" = "bar"
  "baz" = "bar"
}

Where the keys are different, but they contain the same value

In terms of which key to keep, it doesn’t actually matter in may case.

Although, in your above example I’d say the key was on the left. So, more your second option than that the one directly above.

{
  "key1" = "url1"
  "key2" = "url1"
  "key3" = "url3"
}

So what I’d like to get to is

{
  "key1" = "url1"
  "key3" = "url3"
}

right

yep, we’re on the same page

I’m thinking something with the merge function https://www.terraform.io/docs/configuration/functions/merge.html

still pondering

I wondered if I could have done something via a for loop and contains but that only looks to work if I make a copy of the map and they basically loop over it and say add it to map3 if value is not contained in map2. As TF complains if I try and refer back to myself while iterating through the loop. This might be the only way to do it; it just didn’t feel the most optimal or possibly even correct approach. I’ve a bad habit of overcomplicating things, when a simpler answer exists.

you stumped me

I’ve stumped myself on every twist and turn with terraform. So, its not an unusual feeling for me. Thank you for taking the time to make some suggestions.

i would stop and ask, why is my data model like this, and can i rework the data model to function better in the context of the tooling?

but, you can probably do something with the functions for set math. that can tell you which values are in both sets, which values are missing from a set, etc…

https://www.terraform.io/docs/configuration/functions/setsubtract.html

Hi Loren, as ever you do make a very valid point regarding the data set. I think the short answer is… its 100% my fault. I have a data structure (map(opjects)) that I loop over and gather some information, basically just 3 configuration that represent multiple sites

stuff = { for config_key, config in var.site_configs2 : config_key => config.s3_config.s3_bucketname if config.s3_config.s3_create == true }

stuff = {
   authoring   = "assets.mydomainname.test"
   cms         = "assets.mydomainanme.test"
   maintenance = "assets.maintenance.mydomainname.test"
}

Some websites are only host headers but have somethings that access S3 so have the same s3 bucket specified as another config. setting the if config.s3_config.s3_create == true has worked around around the problem as I can set it to false on the sites that are just headers but I’m not sure I’ll be able to do that for ever. So was looking to simply remove the duplicates.

The key is important only because the for_each creating the s3 bucket should be named based on the key, so I can easily reference it by the known name of the key when creating other resources.

Sorry, hope that makes some level of sense. in terms of the explanation. Probably not my rational for structuring it the way I have. I’ll have a look at setsubtract, thank you for the advice.

It’s not possible

Thanks for confirming Alex

@Steve Wade (swade1987) did you try the event pattern that I shared in the previous thread?

wow that would be confusing to debug if you didn’t know this was a thing

Yeah for real. I wouldn’t really want to use honest. Seems like a way to put a bandaid on a larger problem.

imagine an environment without internet access, where module source urls need to be overridden to point at an internally accessible git remote…

That’s a good example… have you used this before / needed that pattern Loren? Do you not check in your override.tf in that case?

i check it in my root, not in public modules

and yes, exactly this use case

Interesting

Wow. It’s this newish?

nah, been using it myself since tf 0.11

Hi @Garth, just by the variable name it looks like you’re having an array instead of a single item. What’s in local.securitygroup_ids?

Here are my locals:

locals {
  security_group_ids = concat(module.networking.security_groups_ids, [module.rds.db_access_sg_id])
  subnet_ids = module.networking.private_subnets_ids
}

do i need to format the lists as strings that the cf template is expecting?

et voila! a join appears to do it.

Thanks @github140 for the hint!

sounds like you might benefit from 0.13 depends_on for modules

@Erik Osterman (Cloud Posse) looks like people are running into alot of cycle issues in 0.13 too. I’ve been running this setup for awhile now (deploy cluster + deploy helm/k8s resources in a single terraform apply + destroy w/o a problem) and its historically worked great. Seems like a possible regression towards the end of 0.12.x that’s also leaked into 0.13?

yes

kinda? depends on what you mean by “terraform tests”…

Yes, indeed.

@jose.amengual @Chris Wahl do you derive value out of those tests? Are you going about it with the terratest process? Do you require passing before applying those root modules?

@loren referring to terratests tests I guess or other terraform testing framework tests.

ahh, no. our roots are comprised of modules, with logic tied together using locals or data sources… no actual resources. we use terratest to exercise each module independently.

That’s what I expected folks to do — Test your reusable modules, but root modules don’t get tested other than actually being used.

because there can be issues threading modules together with that logic, we do have a “mock” account for exercising the root config… the ci pipeline runs a plan against all accounts when a pr is opened for review. when merged to the main branch, the ci runs the apply against the mock account. if that succeeds, and if the “new release” condition is present, then it tags the repo. the ci pipeline picks up the tag event and runs the apply on all accounts

that review pipeline only has read permissions, so it can’t inadvertently do anything

We are using terratest and implementing aws-nuke, the idea is to build e2e integration tests

value=the thing works and here is the report

gotcha. Interesting, thanks gents.

you can’t ask us a question without telling us why you are asking

otherwise we charge for answers

Hahah just wondering what folks in this community do. I’m trying to get my mind around this for a client.

ahh ok

Similar to @loren - our root modules are mostly just calling other modules. I use tflint to check the version being snagged (e.g. “latest” versus a branch / version) and another test just to make sure the module path is still valid (based on a previous issue where someone moved a GitLab project and broke everything).

ohhhhhh interesting

https://github.com/hashicorp/setup-terraform/issues/75

once i run terraform console, then what?

help me not hit this bug pls

I’d be interested in this too. We’re building a github action for TF security review and it will be commenting on the PR too.

Probably your aws provider version is too old

I changed aws provider to 3.20.0. It solves the problem.

you used tf 0.14 to do init ?

or 0.13.5?

if you switch you need to remove the .terraform directory before you try init again

I tried different ways, not knowing what to do, now not sure which version the init happened last. :sweat_smile: I’ll try deleting the .terraform and doing an init again

I deleted the .terraform  and did an init again with 1.13.5 but still getting the state snapshot was created by Terraform v0.14.0, which is newer than current v0.13.5 error.

so your state was upgraded

because you used 0.14

you need to go back to 0.14

it is not 1.13.5 it is 0.13.5 FYI

On 0.14 I’m getting this error as I posted

We are using cloudposse/terraform-aws-elasticache-redis

so you need to push a PR to relax the provider version

like this : https://github.com/cloudposse/terraform-aws-acm-request-certificate/pull/29

This one supposed to relax the provider version of cloudposse/terraform-aws-elasticache-redis, right? It’s not getting merged

We add the allow_overwrite to the ns record and this was solved.

this is provisioned in private subnets

slice(data.terraform_remote_state.vpc.outputs.private_subnets, 0, 2)

I believe you need to configure it without a VPC to allow public access, otherwise you need to create a reverse proxy or use a VPN.

If you do public, make sure you vary the access policy and/or IP restrictions

private subnets can’t be accessed from the internet

yes, agree with @Joe Niland

make sure you protect it (with IP restrictions or password) if you open it to the internet. The AWS IPs are constantly scanned by bots, and your cluster will be hacked in minutes

How about enable NAT? Will it solve the problem?

NAT is from the subnets to the internet

so no, you will not be able to access the cluster behind NAT

So, I need to provision ES with none VPC.

How about I place ES in the public subnets? It should solve the problem?

Have a look at this article @melissa Jenner https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-vpc.html

What is the best practice? If you provision the ES, How will you do?

It depends on the access requirements. What are you trying to do?

The idea case is to be able to access ES behind VPN.

I login to my company via VPN.

And I provision ES.

It looks like attach access_policies may also solve the problem? https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/elasticsearch_domain_policy

{ “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Principal”: { “AWS”: “” }, “Action”: “es:”, “Resource”: “${resource_arn}/*” } ] }

Will it solve the problem if I attach this policy?

That’s at a different layer. First you need to get access to it at the network level. If you’re using a VPN to connect to your VPC that should be ok, although ideally you would lock down the permissions to certain roles or whatever.

Yes. I am using a VPN to connect to my VPC. How to add the access policy I posted above as Terraform code?

I added the line below: iam_role_arns = [“*”] But, I got error. module.elasticsearch.aws_elasticsearch_domain_policy.default[0]: Creating...

Error: InvalidTypeException: Error setting policy: [{ “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “”, “Effect”: “Allow”, “Resource”: [ “arnes12345678:domain/abcd-domain/”, “arnes12345678:domain/abcd-domain” ], “Principal”: { “AWS”: [ “arniam:role/abcd-domain-user”, “” ] } } ] }]

Very cool set up, I think you can solve your problem using backend partial config. https://www.terraform.io/docs/backends/config.html

Exactly the thing I was looking for. I need to read documentation more and more. Thanks @Tom Dugan

From memory it was because of a breaking change in the provider: https://github.com/terraform-providers/terraform-provider-github/issues/502#issuecomment-651627517

Also: https://github.com/cloudposse/terraform-github-repository-webhooks/pull/20

So, if we remove this flag and change this variable in all modules using github-repository-webhooks we will be able to unpin?

perhaps.. maybe a workaround is to set anonymous if token if absent, which is what it mentions here. Best way is to create a PR and test it.

You can thank Github for changing the API again that is why there is this breaking change and we had to pin

Thanks Pepe - ya I think this was our temporary workaround until we could solve it a better way. Otherwise, we’re not about strict pinning like this.

Sounds like you need to submit a pull request to allow the module to work with 0.14

Ya, I think that’s your best bet.

PRs welcome. Post it in #pr-reviews for expedited reviews

Hey Guys, a tiny PR with the required changes: https://github.com/cloudposse/terraform-aws-rds/pull/80

@Jay <https://github.com/cloudposse/terraform-aws-rds-cluster> was updated to support TF 0.14. Please, give it a shot now

@Maxim Mironenko (Cloud Posse) thanks I will check.

Did you copy/paste the command from somewhere? I’m thinking hidden quotes but idk

Not sure if it’s aws-vault throwing the error or what

I have been trying to find the quotes

this started happening after 0.13upgrade was run

@jose.amengual I think the error comes from osascript. Do you have anything weird in ~/.aws/config?

mmmm

let me see

I had some empty duplicated profiles…

I’m checking

same error

yeah, empty profiles should be fine

I do not remember seen this before

this means the email IDs need to be unique across all sites

(I’m guessing your terminology here.)

If that’s true, why not change the initial data structure to:

emails = {
  random_key_name1 = {
    site = "cms"
    email = "[email protected]"
  }
}

Then it’s easier:

resource "aws_ssm_parameter" "mailFromAddress" {
  for_each = local.emails
  name = "${each.value.site}/${each.key}"
  value = each.value.email
}

Hi Alex, The CMS, site2 would be unique, as would each of the keys at the second level. So, yes you could call them email IDs.

1 minute please, just writing a more detailed reply.

Here’s a solution to your exact structure, if you can’t do that:

> local.site_emails
{
  "blog" = {
    "blog_contactus" = "[email protected]"
    "blog_nodeply" = "[email protected]"
  }
  "cms" = {
    "cms_noreply" = "[email protected]"
  }
}
> merge([for site, emails in local.site_emails : { for email_id, email_addr in emails : email_id => email_addr } ]...)
{
  "blog_contactus" = "[email protected]"
  "blog_nodeply" = "[email protected]"
  "cms_noreply" = "[email protected]"
}

I think that might work on this simplified structure I created to ask the question but in reality my real structure is much bigger.

variable "site_configs" {
  type = map(object({
    configuration_name = string
    brand              = string
    primary_url        = string
    subdomains         = list(string)
    domain_name        = string
    environment        = string
    ses_config = object({
      create_ses_user          = bool
      allowed_email_recipients = list(string)
      mailFromAddress_config   = map(string)
    })
    cloudfront_config = object({
      create_cloudfront = bool
    })
    firewall_config = object({
      waf_enabled       = bool
      dedicated_waf_acl = bool
    })
    iis_config = object({
      iis_site_name = string
      site_type     = string
      site_language = string
    })
    s3_config = object({
      s3_create     = bool
      s3_bucketname = string
    })
    ec2_config = object({
      ec2_description = string
    })
    ssl_config = object({
      create_ssl_cert            = bool
      primary_url                = string
      subdomains                 = list(string)
      ssl_description            = string
      ssl_root_domain_names      = map(string)
      ssl_perform_validation     = bool
      ssl_validation_method      = string
      ssl_wait_for_validation    = bool
      ssl_allow_overwrite_dns    = bool
      ssl_transparency_logging   = bool
      ssl_certificate_import     = bool
      ssl_certificate_public_pem = string
      ssl_certificate_chain_pem  = string
      ssl_private_key_key        = string
    })
  }))

}

I’ve used

mailfromAddresses = { for config_key, config in var.site_configs : config_key => {
    for mykey, myvalue in config.ses_config.mailFromAddress_config : mykey => myvalue
    } if config.ses_config.create_ses_user == true
  }

to generate the simplified output. I posed for this question and what I was going to use as the input to the for_each subject to suggestion from here.

Changes to Outputs:
  + test = {
      + cms = {
          + mailFrom2       = "[email protected]"
          + mailFromAddress = "[email protected]"
        },
      + mysite2 = {
          + site2email      = "[email protected]"
          + mailFromAddress = "[email protected]"
        }

    }

The data from the mailFromAddress_config section of the site_config is later used within userdata to perform build transform within other configuration files.

right. that makes sense. Then you can change the key to be a concatenation of site ID and email ID with something like

> merge([for site, emails in local.site_emails : { for email_id, email_addr in emails : "${site}-${email_id}" => email_addr } ]...)
{
  "blog-blog_contactus" = "[email protected]"
  "blog-blog_nodeply" = "[email protected]"
  "cms-cms_noreply" = "[email protected]"
}

Then there’s no restriction on requiring the keys to be globally unique

okay, I had something similar in terms of the merged site name and other key in my own testing but when I then try and overlay this to the for_each I’m struggling to pull the three pieces of information out.

so in the aws_ssm_parameter resource I need the name value to be

 "/blog/blog_contactus"

and the value to be “[email protected]” would you suggest the last structure you supplied but then to get the key “blog” you simply split ${each.key} based on the “-“ to get the key name back?

maybe it would be better to generate a final structure which is a list:

[
  {  site = "cms", id = "noreply", addr = "[email protected]" },
  ...
]

Then no need to worry about uniqueness constraint at all

okay, I think I’m following. I’ll run some tests on my data structure based on the above and see how far I can get.

I would never have got my head around this on my own, as I’ve not used “…” expression yet and I wouldn’t have thought about merging the list together. So, thank you!

I can confirm

 mailfromAddresses = merge([for configs in keys(var.site_configs) :
    { for a, b in var.site_configs[configs].ses_config.mailFromAddress_config : "${configs}-${a}" => b } if var.site_configs[configs].ses_config.create_ses_user == true
  ]...)

outputs

+ test = {
      + cms-mailFrom2       = "[email protected]"
      + cms-mailFromAddress = "[email protected]"
    }

Which is great! As I think I would be able to split on the “-“ to get back to the key “cms” However, you made one further suggestion but I’m not sure how to use it. Did you mean I should pass the output from local.mailfromAddresses to another local / for loop to remap it or did you mean I should modify the original local.mailfromAddresses to match your new structure in some way. Apologies, if I’m missing the obvious.

The ... operator is VERY poorly documented. In fact I just looked and couldn’t find it documented at all! Can anyone find a docs reference?

I was thinking something like this:

> flatten([for site, emails in local.site_emails : [ for email_id, email_addr in emails : {site = site, id = email_id, addr = email_addr} ] ])
[
  {
    "addr" = "[email protected]"
    "id" = "blog_contactus"
    "site" = "blog"
  },
  {
    "addr" = "[email protected]"
    "id" = "blog_nodeply"
    "site" = "blog"
  },
  {
    "addr" = "[email protected]"
    "id" = "cms_noreply"
    "site" = "cms"
  },
]

Ah, okay, and the for_each would accept that in as an input? I didn’t think for_each could handle a list but I might not be thinking this through properly, it is getting rather late in the UK.

@Alex Jurkiewicz the ... operator has near-zero documentation, and it actually means different things in different contexts (function calls vs for expressions)… here is the original hcl2 spec that describes them… https://github.com/hashicorp/hcl2/blob/master/hcl/hclsyntax/spec.md#functions-and-function-calls

you can also find a reference in the tf docs on for expressions: https://www.terraform.io/docs/configuration/expressions/for.html
Finally, if the result type is an object (using { and } delimiters) then the value result expression can be followed by the ... symbol to group together results that have a common key:

{for s in var.list : substr(s, 0, 1) =
s… if s != “”}

Okay, penny has dropped and I’ve manged to test based around your examples. Can’t thank you enough for taking the time to go through that and making the suggestions. Your last example simplifies it a lot. thank you

Thanks Loren!

i can’t actually find a reference to the function call version of ... in the tf docs…

oh wait, there it is: https://www.terraform.io/docs/configuration/expressions/function-calls.html#expanding-function-arguments
If the arguments to pass to a function are available in a list or tuple value, that value can be expanded into separate arguments. Provide the list value as an argument and follow it with the ... symbol:

min([55, 2453, 2]…)

The expansion symbol is three periods (...), not a Unicode ellipsis character (…). Expansion is a special syntax that is only available in function calls.

hashtag LetUsWriteTerraformInARealLanguage

i recently asked about exactly this operator in the hangops slack, so i feel your pain

but the question and the answer have aged out of their slack

so many *ops slacks! Is that one any good? Can you share an invite?

I feel like hangops is one of the oldest, but cloudposse is one of the best. I’m only in that one cuz some of the hashi folks occasionally are active

https://signup.hangops.com/

What I’ve done before is create the db one time, then snapshot it, then use the snapshot as the starting point for subsequent rds instances…

here you go: https://github.com/plus3it/terraform-aws-org-new-account-trust-policy

in particular, the cloudwatch event pattern: https://github.com/plus3it/terraform-aws-org-new-account-trust-policy/blob/d79ef768c34a052dab10cf5e0e3f5353fd10fcf7/main.tf#L63-L79

the issue is the account will already exist

bootstrapping an account implies it is a new account or an invited account

its going to be when we bootstrap the account with other stuff i basically want to write a lambda that optionally adds the account to fugue.co

we have two TF roots

• tf-organisation where the accounts are listed

• tf-accounts where we add baseline stuff to the account

i want to create the lambda optionally from tf-accounts when we add the baseline config

create an event rule for the new account, use a schedule, set the schedule to run once

makes sense

Does it have to be complicated? A lambda can be triggered from terraform on demand…

Guess it would need some form of persistence after it did trigger for that particular account so it only happens the first run.

It could also be handled fully in terraform with triggers

1. i don’t recall having a reorder issue, but i also have not upgraded to 0.14

2. if you’re using remote state with object versioning then try reverting the remote object to the previous version. you can also try starting with a fresh state, then terraform plan (do not apply) and terraform import the resource names returned by the plan. i don’t think terraform refresh can save you in this case.

Thanks for sharing

The only way around it currently as I understand. Have had similar situation with some upstream alb modules and the min/max/desired …

I’m learning to accept it and just live with the fact that if it’s in a module at least it’s “hidden” so what do I actually care once the module does what it’s supposed to.

This will be great.

@Jeremy G (Cloud Posse)

this is probably not the best channel for this question as its not terrraform related but have you checked out XMLStarlet

xsltproc could be useful to if you have a xslt

i just want to add

<init-param>
    <param-name>DisableTaskScheduler</param-name>
    <param-value>FALSE</param-value>
  </init-param>

Why bash?! Do it in a language which can parse XML and you will be a happier man

I guess bash is suitable if you want to append or prepend it. But as soon as you get to the “grep for a certain string and add my snippet after that” you are writing a future bomb IMNSHO

Moving a client onto Terraform Cloud and I believe my path forward involves including the K8s client certificates as the authentication mechanism + aws-auth role for my AWS Terraform CI creds. But if anyone has a “you only need to do X, Y, and Z” approach that’d be awesome.

Using an IAM role you can configure the kubernetes provider with something like:

data "aws_eks_cluster" "cluster" {
  name = var.cluster_name
}

data "aws_eks_cluster_auth" "cluster" {
  name = var.cluster_name
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
}

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.cluster.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
    token                  = data.aws_eks_cluster_auth.cluster.token
    load_config_file       = false
  }
}

Ah good stuff @Tim Birkett — Thanks.

And regarding the IAM role — You’re referring to the user / AWS creds provider to TFC having a role within the cluster, correct?

So you’d have an IAM role that your CI (TFC?) would use, then you’d need a role mapping in the aws-auth config map as described here: https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html#awsdocs-filter-selector<i class="em em-~"</i>text=Add%20your%20IAM%20users%2C%20roles%2C%20or%20AWS%20accounts%20to%20the%20configMap>.

That could link to system:masters but probably shouldn’t

I’m getting the error

error creating RDS cluster: InvalidParameterCombination: Cannot specify user name for cross region replication cluster

I’m wondering if this is because I haven’t set the field global_cluster_identifier. Anyone had this issue before?

are you trying to setup a global cluster ?

or a replica cluster

anything global_ is for global databases which are different than replica clusters using regular DB replication

I want to setup a regular db replica cluster

so you want to setup the replica_source_identifier

no user or pass word

you can leave them as = ""

ahhh I didn’t leave them as empty strings

maybe that’s what I’m missing

they are required but for the replica they need to be empty

got it!

trying it out now

@jose.amengual is it possible to make this replica in the same region?

no

that is an AWS restriction

cool that’s what I thought.

Sorry, I think I was confused when I said i wanted a replica earlier. I want to establish a read replica. Does this template have the ability to do that?

yes

ohhhh read replica

I think I need this one https://github.com/cloudposse/terraform-aws-rds-replica

just change the size to 2

the size of the primary?

a read replica alongside the writer in the same region, vpc ?

yes the use case is to have a primary DB that’s core to the application and another DB that is fed all the data from the primary (like a read replica would do) and then I want to hook up the read replica to a Bi reporting tool like tableau

but you want a replica not a cluster replica

?

I believe I only need a replica. Just somethign that will always stay up to date with my primary DB

We use aurora postgres though and it doesn’t look like that is supported

Oh nevermind this cloudposse doc is old. Aurora does support it

yes we use postgress replicas

there is more tendency to use cluster replicas than single instances

is there any reason why it has to be an instance?

I do not think there is much price difference

I think I’m going to just bump the numder of instances in the aurora cluster up by 1

if you need to read from it is the fastest way to do it

Okay right on

you can add more than one read replica

Thanks this worked!

nool

@jose.amengual I have a quick question about the behavior of the reader node on aurora postgres. So after following what you said yesterday i have a reader node that’s now apart of my aurora cluster. it gives me a specific endpoint to connect to it, but doesn’t have a master password or master username. Do you know how I can connect to specifcally that node or is that even possible?

the reader node uses the same creds that then writer

usually I create user with select access grants

interesting when I use the same master credentials on the reader endpoint it tells me “that role doesn’t exist”

weird

unless is still replicating….

hmm, I thought the connection string would be the “reader_endpoint” that’s outlines in the terraform docs, but when going to the RDS console it looks different

they should be the same

on has ro in the name

the other one does not

that’s what I thought.

but in the console the endpoint looks a bit different.

so in the console if you click on the main cluster resource in rds it shows two endpoints: reader and writer, but if you click on the actual reader node the endpoint looks different.

it appends a -2 to the end of the string like “<RDS NAME>-1.<RDS ID>.<REGION>.rds.amazonaws.com

yes that is normal

one is the Cluster enpoint

the other is the Instance endpoint

each instance endpoint have its own

the cluster endpoint have two

r/o and r/w endpoint

is always better to use the cluster endpoint

if you need to read you use the reader endpoint

okay gotcha

Can you create a random_string resource with for_each and then reference the results?

no, the random_string must be applied for it’s result to be known

only variables, data sources, and builtin functions are known before apply

hence the cuteness here with uuid() and a null_resource that also ignores its own triggers, to create a random value that does not change from one apply to the next

Hm maybe I misunderstood the use case?

You want to create a for_each resource block where the number of resources depends on the output of another resource?

well yes, but i know that doesn’t work. but the use case is very targeted here. i need an random value that doesn’t change from apply to apply, and to use that value as part of the for_each expression

i have some modules that use for_each with a list of objects, each with a “name” attribute. pretty standard. but in my tests, i want to give each object a generated id

in the code above, i generate an id using uuid(), then i store it in null_resource.id and ignore changes to the trigger to make it static. this works fine.

then i try to use a for_each expression to resolve the value from either null_resource.id or local.id. the first will not work on first apply but will subsequently. the second will work on first apply but will change every subsequent apply

  for_each = try(toset([null_resource.id.triggers.id]), toset([local.id]))

but it seems terraform doesn’t even try to resolve the expression. it just sees the reference to null_resource.id and gives up

So the use case is something like a module with an input variable number_of_rds_instances and you want to create that many aws_rds_instance resources, with a random but fixed name for each

Why the need to use the random string in the for each? Pass the random_id to the name variable to all those modules? I don’t fully understand but I’m curious

I use random_string, random_id, random_password for quite a few things. It seems very static to me…

indeed, we got a little sidetracked from the question. the module is what the module is. it uses for_each on the name attribute of this list of objects. if the module is invoked in a way where the name attribute is set using the output of a random_* resource, then you get the error “cannot be determined until apply”.

i am making zero claims disputing that random_* resources generate static values, just that they do not work as inputs for the for_each key…

sorry. I don’t understand why this format won’t work:

variable number_of_ec2_instances {
  type = number
}

resource random_id default {
  count = var.number_of_ec2_instances
}

resource aws_ec2_instance default {
  count = var.number_of_ec2_instances

  tags {
    Name = random_id.default[count.index].result
  }
}

i make no claims about that construction. that is using a static var with count. i am generating the value with terraform and using for_each

if i expose a variable, and generate the random value outside terraform, that certainly works. that’s my backup plan. i was just trying to avoid having the variable, and keeping it all within the tf config

The problem was uuid() and my assumption that functions were resolved in the plan phase (apparently that’s not always true). Switched to a data source that has a random output and got something working. Will post code in the morning

here’s what i came up with… null_data_source outputs a random value, and it is resolved in the plan phase, so this works:

locals {
  random_id = substr(md5(data.null_data_source.id.random),0,8)

  id = try(null_resource.id.triggers.id, local.random_id)
}

data null_data_source id {}

resource null_resource id {
  triggers = {
    id = local.random_id
  }

  lifecycle {
    ignore_changes = [
      triggers,
    ]
  }
}

resource null_resource this {
  for_each = toset([local.id])
}

ok very simple solution

cleaned_pattern = {
    for label, value in var.cloudwatch_event_rule_pattern :
    label => value if length(value) > 0
  }

so far I have solved two issue: • when recreating the cluster ( due to changing servers size ), the terraform resources “kubernetes_namespace” where not destroyed from the tfstate. So I have remove them manually • I am using RBAC to filter access and the above null_ressource wait_for_cluster call  wget --no-check-certificate -O - -q API_ENDPOINT and failed to authenticate

• so for now I just check that the clusterid exists before creating the namespace

Are you planning to run it using aws_lambda_invocation ?

Hello Joe, Honest answer, is I’ve not fully thought this through. I was starting by thinking could I read the output from a Lambda in as a source. Hadn’t given a thought as to how that Lambda would be executed but looking at aws_lambda_invocation it looks the most logical but really am open to any suggestions

The other option to achieve the same thing would be to have a data source that could make a web request and use the response as the input but I’m not aware of a way to do that either.

Hey Gareth, For the second one you can use https://registry.terraform.io/providers/hashicorp/http/latest/docs/data-sources/http

Many thanks Joe, I’ve not come across that provider. Not really sure how I’ve overlooked it before but given what I’m trying to achieve, this might be the simplest way around my scenario. Thanks for taking the time to reply.

np, that provider is actually pretty simple but powerful!

so your Lambda will call WinRM on each server?

What I’ll probably do is create a endpoint that points the to the lambda and then either return the data for terraform to then write to the ssm parameter store for later retrieval by the user data when a machine boots or I’ll I’ll supply something along with the web request and get the lambda to write to the ssm parameter store.

Currently, I tend to pull most security items from the ssm parameter store on boot via userdata. Which Help keep it out of the session state and removed from the admins etc etc. Each instance of an ASG knows which products its responsible for and then just reads in the required values.

Probably a lot of reasons not to do it this way, that I’ve not thought about e.g. use a chef style agent etc but it works for us.

that said, if somebody things I’m opening myself up for problems, feel free to shout. Always whiling to listen to reason

yeah calling them to generate and store then return the ssm key seems secure enough

Thanks again for the help

you’re welcome

that null_resource approach doesn’t seem necessary at all, anymore. could just use a for expression

I haven’t listened to it yet, but I think there was a lot of talk on this topic in the last #office-hours

Nevermind, sounds you listened to it based on your follow-up comment

@Rhys Davies For Scalr:

1. Transition (state) - First you’ll want to migrate existing state, which is straight forward and can be automated//docs.scalr.com/en/latest/migration.html>
2. Transition (workflow) - We would need to understand your current workflow, but whether it is CLI based or vcs based, either are straightforward. If CLI, just add a code snippet to your TF config files and it will start using Scalr to execute the runs. If VCS, just add the repository to Scalr and kick off a run or have it automatically execute on the next commit.

Neither of the above require downtime. You won’t need to reprovision infrastructure/services.

In terms of buy-in, this depends on the team you need it from, the area of most importance, or where the biggest pain point is.

1. A few of our smaller customers have gone through SOC2 or other similar compliance reviews lately and Scalr accelerated that for them through audits, policy, etc. Leadership bought in quickly as soon as they saw they could accelerate it.
2. Others have had major issues around an unorganized module process, which caused outages. The template, module registry, and OPA greatly improved their process and standards.
3. The idea of a more efficient PR process or general workflow has been another big one. Many users did not want to babysit the existing DIY workflow. Really not much buy-in needed as the benefit is fairly obvious.
4. Our larger customers get buy-in from the wider orgs through the idea of autonomy and self-service. Many of them call it an app “vending machine”. Teams sign up to use Scalr and they automatically get an environment or workspace created for them and then they are off and running on their own.

Hi @Rhys Davies - for env0:

1. For migration you need to create a new template with your Terraform code at env0, connect your cloud account credentials, and add all the relevant variables, and create an environment with the same workspace name. You can read more here
2. For us the benefits we see with small teams are the following:

• Gitops for continuous deployment and plan on PRs.

• Custom flows, that allows you to run everything in you Terraform pipeline.

• Self service environment management with TTL policies and Scheduling for cost reduction.

• Creating environment for each PR, also a lot of them are using it using Kubernetes.

• Terragrunt support.

• Actual cost over time with correlation to deployments.

• RBAC and plan before apply, which creates a workflow that is similar to a PR for infrastructure changes. Bigger teams buy in to our SAML, Policies, Self service environment management capabilities, OPA, Teams management, environment limits and budget limits. You can read more about our use case here:

1. IaC automation
2. Teams and governance
3. Managed self service Hope it helps, and let us know if you have any questions.

sorry for the late reply guys, I wrote something out and never hit enter. thank you all so much for the explanations and help, really enjoyed the podcast

Thanks!

do you have existing tfstate? are you upgrading from tf 0.12? do you have modules using the fugue provider with incorrect provider/terraform blocks?

this is newly added

the module being called has the following …

provider "fugue" {
  alias = "terraform-runner"
}

terraform providers output?

how can i delete that?

delete it?

if that module is not using any fugue resources, then you can delete it

is this not correct though in that module …

provider "aws" {
  alias = "terraform-runner"
}

provider "fugue" {
  alias = "terraform-runner"
}

as that module will optionally create resources via the fugue provider