#terraform (2024-05)
Discussions related to Terraform or Terraform Modules
Archive: https://archive.sweetops.com/terraform/
2024-05-01
Hi Team, i am trying to create read replica for document DB with different instance class than primary
module "documentdb_cluster" {
source = "cloudposse/documentdb-cluster/aws"
since instance_class is string i cannot have different instance class for my read replica - any suggestions on this ? how do i have different instance class for my replica (edited)
v1.9.0-alpha20240501 1.9.0-alpha20240501 (May 1, 2024) ENHANCEMENTS:
terraform console: Now has basic support for multi-line input in interactive mode. (#34822) If an entered line contains opening paretheses/etc that are not closed, Terraform will await another line of input to complete the expression. This initial implementation is primarily intended…
2024-05-02
Super cool experiment in the 1.9 alpha release, they’re looking for feedback if you want to give it a go… https://discuss.hashicorp.com/t/experiment-feedback-input-variable-validation-can-cross-reference-other-objects/66644
2024-05-03
:wave: Hello, team!
I am having a slight issue with your terraform-aws-lambda-elasticsearch-cleanup module. It use to work fine, but since I upgrade the TF AWS provider to 5.47.0 from 4.20.1 and bumped the pinned module version to 0.14.0 from 0.12.3 I am getting the following error.
I am using Terraform version 1.8.2
Error: External Program Execution Failed
│
│ with module.lambda-elasticsearch-cleanup.module.artifact.data.external.curl[0],
│ on .terraform/modules/lambda-elasticsearch-cleanup.artifact/main.tf line 3, in data "external" "curl":
│ 3: program = concat(["curl"], var.curl_arguments, ["--write-out", "{\"success\": \"true\", \"filename_effective\": \"%%{filename_effective}\"}", "-o", local.output_file, local.url])
│
│ The data source received an unexpected error while attempting to execute
│ the program.
│
│ Program: /usr/bin/curl
│ Error Message: curl: (22) The requested URL returned error: 404
│
│ State: exit status 22
Have I missed an upgrade step somewhere or is there an issue with the file?
Hrmmm… I have a theory. We recently rolled out some new workflows, maybe the artifact wasn’t produced.
@Igor Rodionov can you take a look?
Essentially, what the module does is a clever hack to download the artifact from S3 based on the commit SHA of the module version you are pulling
For some reason, the commit sha corresponding to that module version does not exist, which leads me to believe there’s a problem with the artfact and something wrong with the pipeline
Thanks for getting back to me. Would this not effect all users then?
Yep
….all users using it at that version
For now, try an older version
ok… standby
Issue with an older version of the module is that AWS TF provider 5 has depreciated some calls.
"source_json" and
override_json
I gotcha… so this is a problem, especially if you manage the terraform-aws-lambda-elasticsearch-cleanup in the same life cycle as, say, your elastic search cluster. While that’s not unreasonable, and what most probably are doing, it’s an example of why we like to break root modules out by lifecycle, reducing the tight coupling and dependencies on provider versions. That said, I totally get why this is a problem, just explaining why we (cloud posse) are less affected by these types of changes.
Makes sense . I just grouped things together that went together. Ending up in this situation.
Thanks for understanding… We’ll get this fixed, just cannot commit to when that will be.
No issues, this is just on my upgrade TF branch and not on master. So I am good for now
2024-05-04
Announcement: In support of using OpenTofu, starting with Geodesic v2.11.0, we are pre-installing package repos to allow you to easily install OpenTofu in your Dockerfile.
ARG OPEN_TOFU_VERSION=1.6.2
RUN apt-get update && apt-get install tofu=${OPEN_TOFU_VERSION}
2024-05-05
Guys is this normal behavior? In AWS EKS I have upgraded my nodes into t3.large from t3.medium, I saw before confirming “yes” that terraform will destroy the old nodes in order to proceed with the upgrade but I didn’t expect it to delete the volumes as well, good thing it only happened in our testing environment, my question is this normal behavior if I upgrade the instance_types? Because I was hoping to be able to upgrade it without affecting my persistent volumes