#terraform (2022-10)

https://github.com/cloudposse/terraform-aws-sns-cloudwatch-sns-alarms

or maybe https://github.com/cloudposse/terraform-aws-ecs-cloudwatch-sns-alarms ?

Yes. Mostly because I found the cloudwatch RDS module with already some alarms in it. And I was wonder the ec2 with already pre-defined alarms, threshold and so. And, no, any of the previous one has that. Looks like the module is now private?

@RB

Please post the plan

Maybe its the log bucket from the 0.38.0 release ? Just guessing tho.

https://github.com/cloudposse/terraform-aws-tfstate-backend/releases

Plan with bucket_enabled = true:

Terraform will perform the following actions:

  # module.tfstate-backend.aws_s3_bucket.default[0] will be created
  + resource "aws_s3_bucket" "default" {
      + acceleration_status         = (known after apply)
      + acl                         = "private"
      + arn                         = (known after apply)
      + bucket                      = "XXXXXXXX-terraform"
      + bucket_domain_name          = (known after apply)
      + bucket_regional_domain_name = (known after apply)
      + force_destroy               = false
      + hosted_zone_id              = (known after apply)
      + id                          = (known after apply)
      + object_lock_enabled         = (known after apply)
      + policy                      = jsonencode(
            {
              + Statement = [
                  + {
                      + Action    = "s3:PutObject"
                      + Condition = {
                          + StringNotEquals = {
                              + "s3:x-amz-server-side-encryption" = [
                                  + "AES256",
                                  + "aws:kms",
                                ]
                            }
                        }
                      + Effect    = "Deny"
                      + Principal = {
                          + AWS = "*"
                        }
                      + Resource  = "arn:aws:s3:::XXXXXXXX-terraform/*"
                      + Sid       = "DenyIncorrectEncryptionHeader"
                    },
                  + {
                      + Action    = "s3:PutObject"
                      + Condition = {
                          + Null = {
                              + "s3:x-amz-server-side-encryption" = "true"
                            }
                        }
                      + Effect    = "Deny"
                      + Principal = {
                          + AWS = "*"
                        }
                      + Resource  = "arn:aws:s3:::XXXXXXXXX-terraform/*"
                      + Sid       = "DenyUnEncryptedObjectUploads"
                    },
                  + {
                      + Action    = "s3:*"
                      + Condition = {
                          + Bool = {
                              + "aws:SecureTransport" = "false"
                            }
                        }
                      + Effect    = "Deny"
                      + Principal = {
                          + AWS = "*"
                        }
                      + Resource  = [
                          + "arn:aws:s3:::XXXXXXX-terraform/*",
                          + "arn:aws:s3:::XXXXXXX-terraform",
                        ]
                      + Sid       = "EnforceTlsRequestsOnly"
                    },
                ]
              + Version   = "2012-10-17"
            }
        )
      + region                      = (known after apply)
      + request_payer               = (known after apply)
      + tags                        = {
          + "Attributes" = "state"
          + "Name"       = "XXXXXXXX-terraform"
          + "Namespace"  = "fp"
          + "Stage"      = "dev"
        }
      + tags_all                    = {
          + "Attributes" = "state"
          + "Name"       = "XXXXXXXX-terraform"
          + "Namespace"  = "fp"
          + "Stage"      = "dev"
        }
      + website_domain              = (known after apply)
      + website_endpoint            = (known after apply)

      + cors_rule {
          + allowed_headers = (known after apply)
          + allowed_methods = (known after apply)
          + allowed_origins = (known after apply)
          + expose_headers  = (known after apply)
          + max_age_seconds = (known after apply)
        }

      + grant {
          + id          = (known after apply)
          + permissions = (known after apply)
          + type        = (known after apply)
          + uri         = (known after apply)
        }

      + lifecycle_rule {
          + abort_incomplete_multipart_upload_days = (known after apply)
          + enabled                                = (known after apply)
          + id                                     = (known after apply)
          + prefix                                 = (known after apply)
          + tags                                   = (known after apply)

          + expiration {
              + date                         = (known after apply)
              + days                         = (known after apply)
              + expired_object_delete_marker = (known after apply)
            }

          + noncurrent_version_expiration {
              + days = (known after apply)
            }

          + noncurrent_version_transition {
              + days          = (known after apply)
              + storage_class = (known after apply)
            }

          + transition {
              + date          = (known after apply)
              + days          = (known after apply)
              + storage_class = (known after apply)
            }
        }

      + logging {
          + target_bucket = (known after apply)
          + target_prefix = (known after apply)
        }

      + object_lock_configuration {
          + object_lock_enabled = (known after apply)

          + rule {
              + default_retention {
                  + days  = (known after apply)
                  + mode  = (known after apply)
                  + years = (known after apply)
                }
            }
        }

      + replication_configuration {
          + role = (known after apply)

          + rules {
              + delete_marker_replication_status = (known after apply)
              + id                               = (known after apply)
              + prefix                           = (known after apply)
              + priority                         = (known after apply)
              + status                           = (known after apply)

              + destination {
                  + account_id         = (known after apply)
                  + bucket             = (known after apply)
                  + replica_kms_key_id = (known after apply)
                  + storage_class      = (known after apply)

                  + access_control_translation {
                      + owner = (known after apply)
                    }

                  + metrics {
                      + minutes = (known after apply)
                      + status  = (known after apply)
                    }

                  + replication_time {
                      + minutes = (known after apply)
                      + status  = (known after apply)
                    }
                }

              + filter {
                  + prefix = (known after apply)
                  + tags   = (known after apply)
                }

              + source_selection_criteria {
                  + sse_kms_encrypted_objects {
                      + enabled = (known after apply)
                    }
                }
            }
        }

      + server_side_encryption_configuration {
          + rule {
              + apply_server_side_encryption_by_default {
                  + sse_algorithm = "AES256"
                }
            }
        }

      + versioning {
          + enabled    = true
          + mfa_delete = false
        }

      + website {
          + error_document           = (known after apply)
          + index_document           = (known after apply)
          + redirect_all_requests_to = (known after apply)
          + routing_rules            = (known after apply)
        }
    }

  # module.tfstate-backend.aws_s3_bucket_public_access_block.default[0] will be created
  + resource "aws_s3_bucket_public_access_block" "default" {
      + block_public_acls       = true
      + block_public_policy     = true
      + bucket                  = (known after apply)
      + id                      = (known after apply)
      + ignore_public_acls      = true
      + restrict_public_buckets = true
    }

  # module.tfstate-backend.local_file.terraform_backend_config[0] will be created
  + resource "local_file" "terraform_backend_config" {
      + content              = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0644"
      + filename             = "./backend.tf"
      + id                   = (known after apply)
    }

Plan: 3 to add, 0 to change, 0 to destroy.

Plan with bucket_enabled = false

Terraform will perform the following actions:

  # module.tfstate-backend.local_file.terraform_backend_config[0] will be created
  + resource "local_file" "terraform_backend_config" {
      + content              = <<-EOT
            terraform {
              required_version = ">= 0.12.2"

              backend "s3" {
                region         = "us-east-1"
                bucket         = ""
                key            = "rds/terraform.tfstate"
                dynamodb_table = "XXXXXX-rds-state-lock"
                profile        = "XXXXXX-dev"
                role_arn       = ""
                encrypt        = "true"
              }
            }
        EOT
      + directory_permission = "0777"
      + file_permission      = "0644"
      + filename             = "./backend.tf"
      + id                   = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Probably not related but I am getting this deprecation warning:

│ Warning: Argument is deprecated
│
│   with module.tfstate-backend.aws_s3_bucket.default,
│   on .terraform\modules\tfstate-backend\main.tf line 156, in resource "aws_s3_bucket" "default":
│  156: resource "aws_s3_bucket" "default" {
│
│ Use the aws_s3_bucket_server_side_encryption_configuration resource instead

interesting as I’ve used the terraform-aws-tfstate-backend module ourselves and don’t recall an issue… You said you’re using the same bucket but you’re using different keys… are you trying to call the module twice?

no, not calling module twice.

in my case we have 2 instances of terraform-aws-tfstate-backend… deployed in 2 different accounts. Then our key is specified in our deployments via partial backend configurations. Each deployment stores it’s statefile in a subdirectory/folder of the bucket

@jsreed hey thanks mind placing that in a thread response to my post?

Sure

AGREE! doing things for the sake of doing them seems to be popular when doing any kind of IAC. Putting something into version controlled code is busy work for tools like datadog that are SaaS services anyways. Everything as code is a dev mind set, while there are great efficiencies to be had from that, there are places where it doesn’t make sense. Pick the right tool for the job, spend the money on it if it’s comercial, avoid writing your own. The more home brewed tooling you make the worse it is to mantain when the brain trust that made it moves on, and they WILL move on, it creates massive tech debt and added cost down the road.

So code reuse is one “pro” I didn’t cover that a friend brought up so I figured I’d add it here.

In other words if everything is in IaC then when new services come online they can basically just copy-pasta their way into fast-and-easy IaC.

I can definitely see this being useful for making large dashboards. Although they can just be cloned in the UI!

Yes; management at scale is an important thing. Also, different platforms make it harder or easier to enforce roles and policies. By having it in code, it is easier to enforce general guardrails and empower teams to be autonomous without needing to provide direct admin access

atmos has added json schema and opa for this reason

I find that pattern more common when teams make thier own tooling… and leverage graphana etc… and totally right copy paste is a big plus with that kind of deployment… but with comercial tooling it’s not necessary. I always try to keep focus on what does the business “do”? Is it developing IT tooling, great then making this stuff makes sense. If you’re running an online quilting supply store, it doesn’t make sense wasting money/cycles on developing and maintaining tooling.

Something like the terraformer approach described above is only talking about BCP/DR, but not how to manage monitoring at scale. The most common pattern for that is some kind of abstraction that works for you business.

Lets discuss on #office-hours tomorrow

@Erik Osterman (Cloud Posse) yeah I’ll be there. Curious to get people’s feedback on this because now that I’m staring at it I’m not sure I really care. But maybe I just don’t see the bigger picture.

I think in my case too the SCIM portion is not relevant here because we have an IT team that handles all that via Okta clickops.

Although maybe they wouldn’t if we offered them a TF approach? Not sure – all their scim is of course backed by AD.

Anyway yeah I’ll bring it up at office hours.

Also yeah Erik fyi my focus is not at all about BCP/DR. It’s about managing observability at scale: just like you put it.

Basically: so everyone’s dashboards are in datadog and browser memory only: who cares? I mean do we really need to lock down who can change what in a monitor or dashboard? Are we really going to make datadog read only and push all changes through IaC? Who cares – no one really goes into dashboards and screws them up. I can’t think of one time where that’s happened. I suppose it happens from time to time with metrics, monitors, SLOs etc. but meh – not that much.

I’m also keen to hear thoughts on this in #office-hours Maybe one benefit to the IaC approach is the ability to document and structure what’s configured with more detail, close to the infrastructure and services that are being monitored. It’s easy to end up with 300 dashboards and monitors that aren’t immediately clear in what they’re for, and afaik DataDog doesn’t have many good options for this (though I haven’t been using it recently).

Awesome.

Yeah so far the main arguments are:

• reusability

• auditing

• easier search, i.e. easier to search github? dubious claim lol So basically nothing new there from a devops best practices perspective.

We use IaC for monitoring / alerting when developing our various service offerings. This ensure consistency between various resources.

We click-ops’d this for a long time and just had really big rules covering multiple resources. This ended up over time resulting in less granularity / visibility into problems in our environment as it grew to multiple different companies.

We found that the initial setup of this was painful, but when considering the long term because we also leverage gitops this resulted in a significant reduction in hands on for monitoring/alerting setup and upkeep.

I will advise of one caution though. If your monitoring provider decides to significantly change their monitoring/alerting (see newrelic) this is pain.

Awesome, thanks @Chris Dobbyn. Yeah I guess if one needed to roll a ton of monitors and dashboards maybe that would be useful.

One thing I’m starting to understand is that not many people have experience coding up a ton of observability and really staying on top of that, at least not as far as I can tell. So there isn’t a ton of data on how useful it is compared to other potential work.

For example this article, by head of product at dynatrace, is utterly uninspiring:

• https://thenewstack.io/why-developers-need-observability-as-code/

Few of the reasons I’ve always imagined I want devs to define dashboards in code:

• same dashboards (and alarms) deployed across stages (dev/prod parity) - seen lots of things in prod that could have been caught in dev (but maybe I’m kidding myself that they would have been)

• sense of devs owning the dashboards that they ‘hand over’ to the rest of the business as part of the ‘this thing is done now, here’s how we know it’s working’

• Keep the dashboard definition with the app code If I ever get to the maturity level where this is happening, I’ll let you know whether it worked

Thank you @david.gregory_slack. I’ll be broaching this topic during office hours today in case you’re interested.

Was planning to attend but gonna miss it! Will try to catch you tomorrow!

i wish.. couldn’t make it.. next year

@managedkaos let me know if you make it here today

I’m here! Was wondering where you would broadcast from. I’ll be on zoom for sure.

Set the node_role_arn variable. You should be able to get this from the output of your first node group eks_node_group_role_arn.

Yes, here’s how we do it https://github.com/cloudposse/terraform-aws-components/tree/master/modules/eks/cluster

Personally, my advice is to copy the defaults to new at any rate, thereby reducing the requirement to change it off of default should you need to change these in the future, especially when you get to db performance optimisations

when you need to tweak the parameters of one database at 3am during an outage, you will appreciate having a dedicated set of parameter groups for each cluster. Request the limit increase and be happy you are successful enough to need limit increases

Many thanks. Then I will proceed.

Hrmm… we definitely source provider configurations from the output of other modules

https://github.com/cloudposse/terraform-aws-components/blob/master/modules/acm/providers.tf#L4

…that’s an example

Hey @Erik Osterman (Cloud Posse), so I think a key constraint in my use-case was that the modules (say: A and B) belonged to the same state. Which I believe renders it impossible in my case - as plans would become impossible, given that the provider for module B depends upon post-apply data from module A

that begs the question then is this the right architecture of root modules?

I’m considering two different states: one containing a module named db, and the other containing a module db_config. db creates the generic underlying data store, and db_config applies additional configuration on top of it (e.g. schemas). This enables the provider passed to db_config to successfully obtain post-apply data for the user store (i.e. hostname) for connecting to it and planning its provisioning operations, upon plan of db_config (given that db will already be successfully applied by this stage)

Is that the kind of architecture you might suggest here?

The issue appears to be related to work done recently to support SANs and complex deployments: https://github.com/cloudposse/terraform-aws-acm-request-certificate/compare/0.16.2...0.17.0

Ah found nitrocode @RB

@Adam Panzer we probably need a new input to verify the zone id using the data source

Lemme look and see if I can figure this out

The problem is that we need a we need to be able to get the r53 zone id to create the necessary r53 records

And how do we distinguish between one zone id and another if the sans are in diff subdomains

oh, it’s the split

two sans in two different zones

it’s always dns

Feel free to put in a pr if you have a good fix and we can continue the discussion there

yup. thanks for the fast response

Question: Instead of guessing / trying to figure out which zone to use, why not just have the person give it to you, be explicit:

subject_alternative_names = [
  {
    zone_to_lookup = "foo.baz.com",
    names          = ["a.foo.baz.com", "b.foo.baz.com"]
  },
  {
    zone_to_lookup = "*.baz.com",
    names          = ["bob.baz.com", "alice.baz.com"]
  }
]

The iterating might be … messy tho

@Adam Panzer could you create a ticket for now in the upstream module

you can also set var.process_domain_validation_options=false to disable appending the acm cert verification record to each route53 zone to get around the failure

Yeah. Will do. Which upstream module though? It’s just <https://github.com/cloudposse/terraform-aws-acm-request-certificate>

Please add a ticket to https://github.com/cloudposse/terraform-aws-acm-request-certificate

will do

done: https://github.com/cloudposse/terraform-aws-acm-request-certificate/issues/62

thank you

please mention if var.process_domain_validation_options=false workaround works for you

That probably would work but I’ve pinned it to the previous version for now too, which worked fine

I had other modules on that version anyways

(other copies of that mod)

could you also explain which zone each of your domain and subdomains are in

and could you show what zones it tried to add the records to ?

any additional info that can help understand the issue would be helpful

including your proposal in this slack thread

please and thank you.

I will say, I’m slightly worried I’m just not understanding DNS that well

<haiku_its_dns.jpg>

I think you’re correct. I think the best way is to specify the zone id or zone name to look up for each san.

@RB wait, is trying to traverse one back from the domain? Should the domain actually be bar.com not the subdomain?

depends on where you want the record. i think right now, it assumes you want it in a hosted zone one level up from the domain.

e.g. [foo.baz.bar.com](http://foo.baz.bar.com) domain would be in [baz.bar.com](http://baz.bar.com) zone

Yeah, and if the Domain were bar.com it wouldn’t be possible to go “one up”

I guess is it going to do the same for the SANs too

@Adam Panzer another workaround, could you specify the zone_name or zone_id inputs and see if that works as expected for you ?

Yup, gimme a few

Did it work

Sorry. Startup life is chaotic. I’ll get to this today!

I’m going to pull this up now

soooon https://github.com/hashicorp/terraform-provider-aws/pull/26990

more context, I am trying to make a wrapper module for https://github.com/nozaq/terraform-aws-secure-baseline/

I think I have found answer in the documentation

A module intended to be called by one or more other modules must not contain any provider blocks. A module containing its own provider configurations is not compatible with the for_each, count, and depends_on arguments that were introduced in Terraform v0.13

"${aws_s3_bucket.opensearch-backup.arn}" → aws_s3_bucket.opensearch-backup.arn isn’t that all you need to do?

Which aws provider version is this? I don’t see the aws_instance having the ip_address argument? The example in docs is:

resource "aws_network_interface" "foo" {
  subnet_id   = aws_subnet.my_subnet.id
  private_ips = ["172.16.10.100"]

  tags = {
    Name = "primary_network_interface"
  }
}

resource "aws_instance" "foo" {
  ami           = "ami-005e54dee72cc1d00" # us-west-2
  instance_type = "t2.micro"

  network_interface {
    network_interface_id = aws_network_interface.foo.id
    device_index         = 0
  }

  credit_specification {
    cpu_credits = "unlimited"
  }
}

I’ve used to use the

private_ip = "x.x.x.x"

You can use local-exec.

Related https://github.com/cloudposse/terraform-null-smtp-mail

maybe the join function can help here?

> join(",", ["group1", "group2", "group3"])
"group1,group2,group3"

I actually think I’m probably overbuilding this, pivoted my solution now, cheers anyway!

Hi Muhammad. It’s difficult to see what is causing the error without all of the inputs to the module. Please share them when you have time

this is expected behavior - when you use a list/set in for_each, TF creates a list of resources with the same indexes as the list - when the list indexes are changed (removed, moved, etc.), TF has to recreate all the resources

use maps in for_each - this way, TF creates a map of resources, and since the keys in the map do not change, TF will not recreate them

Interesting, I expected a set to function similarly (as the abstract notion of a set doesn’t have indices)

I was slightly incorrect in my description: I have a data source with for_each = my_resource and that resource has a for_each = [var.my](http://var.my)_map). The keys match, given the use of maps - action_reason is read_because_dependency_pending on the data source

The data source refers to each.value.some_attribute - so given that the keys align, and my_resource["the_key"] isn’t being changed in the plan - each.value.some_attribute should be fetching a known value of that unchanged attribute already in the state

I can manually construct the some_attribute value inside of the data source, relying only upon the key (from for_each = my_resource), but to not be able to take advantage of depending upon some_attribute when the resource isn’t even changed is bizarre

Sort-of solved, but a mystery with the AWS provider remains.

Concretely, the data source was an aws_iam_policy_document. Removing that data source and jsonencode()‘ing a similar document within the referring AWS resource worked fine.

Interestingly, the attributes of that data source all appear to be known except json and id (from observing terraform show -json on the plan).

How json couldn’t be known, yet all the attributes that make it up are known, is a mystery to me. Well, avoiding that data source and its strange behavior is a workaround..!

I’ve seen this before. It often manifests where AWS changes your applied document. It could appear as an added or remove newline, extra spaces. It’s quite frustrating when it appears.

Sometimes this can be fixed prior to apply, but your workaround works as well.

this is expected behavior - when you use a list/set in for_each, TF creates a list of resources with the same indexes as the list - when the list indexes are changed (removed, moved, etc.), TF has to recreate all the resources I don’t think this is correct @Andriy Knysh (Cloud Posse).

With a simple configuration like

resource "null_resource" "this" {
  for_each = toset(["a", "b"])
}

if you apply this, then remove a and add c, it won’t touch b. The resources are indexed by item value.

yes, you are correct, I’ve mixed that up with lists/sets in count

Of course, thank you.

What’s your opinion of something like atmos vs a well-configured terragrunt project?

I’m using modules / components in terragrunt and I feel forced to use for_each on all of my components because you cannot use for_each in terragrunt.hcl. Nor is there another method that I know of like atmos uses to reference the same component multiple times in a stack.

our opinion is to use atmos, but we are biased since we created it

let us know if you need help with atmos and with configuring components and stacks

@Andriy Knysh (Cloud Posse) That would be great. I’d like to evaluate atmos and Spacelift. Would you have the time to join a video call?

sorry not right now (having a bunch of meetings). @Linda Pham (Cloud Posse) please schedule a call, maybe tomorrow

No worries. Thank you. Let me know what time works best for you @Linda Pham (Cloud Posse)

@Zach B, can you send out the invite to @Andriy Knysh (Cloud Posse)? He’s available between 8a-1p PST. I’ll DM you his email

@Linda Pham (Cloud Posse) Yes of course

You should post this in #pr-reviews

alright, thanks

My experience is that a policy using OAI is set up by default when using the cloudfront-s3-cdn module.

Looks something like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3GetObjectForCloudFront",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity **************"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::**************/***************"
        },
        {
            "Sid": "S3ListBucketForCloudFront",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity **************"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::**************"
        },
        {
            "Sid": "ForceSSLOnlyAccess",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::**************/*",
                "arn:aws:s3:::**************"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

I can’t say that i’m familiar with the DD lambda forwarder per se, however: i just tried to set up a DD->AWS integration yesterday using the DD provided CloudFormation template and the stack deployment failed because the lambda forwarder did not install properly. any chance you are having the same problem?

On TF_LOG_CORE I’m getting a 403, looking into this

Turns out it was a really tricky mistake: I had forgotten to set the bucket name variable value for a remote state data source, and the default value was an existing bucket in *another* aws account.

This explains why cloudtrail did not pick anything up in the account where we were running terraform: the request was going to the other account! (luckily that account was also my client’s, otherwise some org might have been wondering who kept trying to access their state bucket! )

Also, the access denied error appeared in the core logs rather than provider logs… actually there is a lot of aws-provider output in the core logs, wtf? This greatly decreases the usefulness of TF_LOGS_PROVIDER recently introduced, I’ll continue to use TF_LOGS in the future.

If TF_LOGS_PROVIDER is a recent new feature, perhaps providers need time to utilize this new env var over the old TF_LOG one?

Glad you were able to resolve your issue!

Yeah @RB I suspect you’re right

You could pass the env value as a tfvar

Then you can use it in terraform

locals {
  production = var.env == "prod"
}

I need to set production to either true or false

It’s part of a set of tags, so in case the env var tell us we are deploying to prod, we tag the resource with production: true

production = "{{ env.ENV_PREFIX }}" == "prod" ? true : false

Got this in my tfvars

Ahh I see, that’s going to work.. Thanks a million

I need to set production to either true or false Ronak’s statement does that. The local.production will be a boolean:

locals {
  production = var.env == "prod"
}

There is no need for a more complicated expression. Moreover you can set TF_VAR_env in the shell to a value, and terraform will set var.env to that value automatically.

We have not done too much with IPv6 yet, but would probably accept PRs extending it.

@Jeremy G (Cloud Posse)

@Erik Osterman (Cloud Posse) I’m not sure we want to continue to support this module. Either way, this is better handled by @Andriy Knysh (Cloud Posse).

@Jeremy G (Cloud Posse) so is there any other moduel do the same in cloudposse ?

@Nitin I was confusing terraform-aws-vpc-peering-multi-account with terraform-aws-vpc-peering-multi-account-request. I think it we probably should continue to support terraform-aws-vpc-peering-multi-account and adding IPv6 support is a natural extension. Unfortunately, this module is not something we can test via our current automated test suite (because it requires 2 accounts), so it makes modifying it more dangerous. This means we need to take extra care, and are likely to take a very long time responding to PR requests from the community.

What you could do, if you are inspired, is open a PR and then use the PR branch in your own environment and report on how it goes. That is the approach we are taking with this change to terraform-aws-eks-cluster that is hard to test for other reasons.

@Jeremy G (Cloud Posse) https://github.com/cloudposse/terraform-aws-vpc-peering-multi-account/pull/67

@Nitin Thank you for the PR. I’m really resistant to using regexes to distinguish IPv4 from IPv6, but at the moment I don’t see a better way, so I guess I will have to live with it.

I’m more confused/concerned about why you had to go beyond cidr_block_associations to find the IPv6 CIDR when it seemed to be all that was needed to find the IPv4 CIDR.

@Jeremy G (Cloud Posse) we want to communicate between two IPv6 resouces over vpc peering

as both resources or destination might be in private subnet

I added a simple tailscale setup for just a few users, but this has been amazing for us. Very easy and performant.

Can you please share me the resource link?

https://tailscale.com/

Is it free?

Thanks.

https://tailscale.com/pricing/

Tailscale is awesome, they’re using wiregaurd. If you want to roll yourr own, I would suggest looking at pritunl, which supports both openvpn as well as wirregaurd

not required, but can serve a different purpose. in reusable modules, the version constraints are typically a min version. in a root module, the constraints tend to be much tighter since they are specific to a given deployment

Thanks. Pet peeve with terraform at the moment is that it actually allows modules to define providers

holdover from old versions, kept for compatibility reasons

Yeah, I gathered as much. I wish everybody else writing terraform got the memo

aye. don’t use provider blocks in reusable modules

If a reusable module uses two providers (A & B), and the providers are configured in the root module, can provider B be configured with outputs of that reusable module (from provider A operations), before running its own operations in that same reusable module?

I can try playing that one out tomorrow, bit wary of this refactor becoming a rabbit-hole with dead-ends etc.

like this, you mean? if so, yes no problem

module "a" {
  providers = {
    aws = aws.a
  }
}

module "b" {
  providers = {
    aws = aws.b
  }

  input = module.a.output
}

the source of each module is rather immaterial to that use case. it can be the same source (and so the same reusable module), or different

One provider is AWS, the other is Kubernetes

The kubernetes provider requires a hostname to connect to, which is produced after an AWS provider operation.

The kubernetes provider config block refers to an aws data source to find that hostname (as part of initializing the provider itself)

Where both providers are within the same module, the Kubernetes provider has visibility on that data source to fetch the value it needs to initialize

However, if I initialize the providers outside of the module, that Kubernetes provider will still need to get that hostname to initialize itself

If that data source value was exposed as an output, I was wondering if I could refer to [module.foo.my](http://module.foo.my)_output in the root module’s Kubernetes provider config block

This would mean that module foo would have to do the AWS stuff, which would be referred to by an output,, and then the Kubernetes provider configured in the root module could get that output value to initialize itself, and the foo module continues on with its Kubernetes stuff

Wasn’t sure if all operations would have to complete in that module before any outputs are exposed, basically

oh, no, the output is available as soon as its dependencies are met

if you want to force an output to wait, you can use depends_on in the output block

Brilliant, that sounds like it permits a sufficiently spaghetti flow for my needs!

yeah, the terraform graph is pretty excellent. sometimes so much that it is confusing!

not required, but can serve a different purpose. Ah, actually is required when using a provider that isn’t authored by HashiCorp, I’ve found

well there is that

are you using latest terraform, 1.3? i don’t recognize the error, but cross-module moves requires 1.3…

The very latest and greatest (1.3.3), I did check the changelogs too

It looks to me like specifying a nested module address in from completely confuses the parser into thinking there isn’t even a to

yeah, my use cases have all been cross-modules moves, but i’m still at 1.2, so haven’t been able to get any real working experience with moved blocks just yet

I was a bit slow on the uptake of trying out moved since it was released, perhaps not slow enough

state mv to the rescue!

perhaps open an issue and see what comes back? also, if you’re in hangops slack, the primary developer of the moved feature is active there. he might chime in if you post the question there

I totally forgot about hangops, thanks for the reminder!

The from and to addresses both use a special addressing syntax that allows selecting modules, resources, and resources inside child modules. I retract my earlier statement, this from the docs themselves is pretty unambiguous about it being positively supported

@loren I’m embarrassed to say it was uh, a rather obvious error on my part.

But I’ll confirm that it works now, so feel free to use it for your cross-module moves when you upgrade

lol c’mon now, spill the beans

Um. I read through changelogs, docs, and everything. But I had a completely empty moved { } at the bottom of the file, and must have neglected to verify the error’s line number

aye! i think we’ve all been there. good reminder for us all to check our assumptions

i’ve probably done this my whole career, but i just learned about rubber ducking as a real thing… https://en.wikipedia.org/wiki/Rubber_duck_debugging

Great for working in total isolation.

I guarantee that my significant other in the house would start responding, thinking I’m calling out, and throw me way out of the zone

haha yeah, often the duck ends up being a coworker or slack workspace

idk but there’s a nifty python module that will do it

there has to be a terraform module to handle this, just google it there are probably 10

Actually google came up empty which is why i posted here

how are you consuming them?

I think they may be just TF_VAR_ envs in the end, which support JSON encoding

can’t quite remember how I solved this but calling terraform variables across modules vs live directories in general is annoying

Sounds like you’ll need to loop over the stack, creating one per backend

Thanks, will try that!

Works, thanks for the hint!

This is a core feature of terragrunt, which I use a lot, so it felt pretty natural to me

Hehe, thanks. You mean the generate feature?

More just lots of stacks, with a backend per stack

But generate and file templating could get you there also

Anotherone then: How to loop over a module and store the state in the same workspace/state?

well you have options using cdktf. you can loop over the module in cdktf, giving each one a unique label. or you can use terraform-native for_each on the module itself.

Don’t bother with cdktf. It will cause you more heartache than success.