#terraform (2024-11)

v1.11.0-alpha20241106 1.11.0-alpha20241106 (November 6, 2024) EXPERIMENTS: Experiments are only enabled in alpha releases of Terraform CLI. The following features are not yet available in stable releases.

terraform test accepts a new option -junit-xml=FILENAME. If specified, and if the test configuration is valid enough to begin executing, then Terraform writes a JUnit XML test result report to the given filename, describing similar information as included in the normal test output. (<a…

One of my devs created a security group in AWS using terraform. He has create_before_destroy set to false Now he needs to replace that SG but can not cause downtime by having the first SG deleted and the recreated. If he sets create_before_destroy to true after the SG already exists will terraform honor that and create the new SG along with rules before destroying the older SG? Im thinking it will but ive never tried it and I dont want to test in prod

Hello everyone, I’m using terraform to deploy all my infrastructure code , from k8s cluster creation to pod deployment, we have multiple environments : develop, staging and prod but we don’t use diffrent branches for our repository, we want to automate the terraform applies, specially for develop and staging and we are wondering what are the existing open source tools that worked for you

Hi everyone,

I’m wanting to use the CloudPosse AWS Config module - https://github.com/cloudposse/terraform-aws-config/tree/main

I’ve read through all the documentation and looked through the complete example provided, but I’m not clear on something, hoping someone has used this before:

I want to set this up at the Org level. We have AWS Organizations setup with several accounts, 2 main ones and some smaller ones, and I want to use this module to setup a proper centralised setup like it recommends on the AWS docs using trusted access via Organisations etc, and what I’m not clear on looking at this module code is if this does this for you automatically or if you need to apply this code to all accounts, the examples provided don’t really mention anything about multi-account setups

v1.10.0-rc1 1.10.0-rc1 (November 13, 2024) NEW FEATURES:

Ephemeral resources: Ephemeral resources are read anew during each phase of Terraform evaluation, and cannot be persisted to state storage. Ephemeral resources always produce ephemeral values. Ephemeral values: Input variables and outputs can now be defined as ephemeral. Ephemeral values may only be used in certain contexts in Terraform configuration, and are not persisted to the plan or state files.

ephemeralasnull function: a function takes a…

Does anyone know of a decent tool that creates decent diagrams from code? The graph command just doesn’t cut it

:wave: Atmos newbie here, loving the product so far and enjoying being able to consume your open source modules! They’re helping make quick work of our new environmental standup and the hiera-style hierarchy is a beautiful thing to see working with TF.

I’m currently working my way through a little bit of a side questing exercise (importing our existing resources into the foundational account, account-map, and tfstate-backendmodules) and am trying to get the account-map module to work correctly (I’m very close, having already gotten account and tfstate-backend functional against existing accounts and OU mappings for our AWS Org).

Currently, I’m running into an issue with account-map where it seems to be trying to load different atmos.yaml settings from some default than what I have specified at my top level and where I run the atmos commands from. Specifically, I’m seeing the following error when trying to run atmos terraform plan account-map --stack sre-bootstrap :

│ Error: failed to find a match for the import '/atmos/components/terraform/account-map/stacks/orgs/**/*.yaml' ('/atmos/components/terraform/account-map/stacks/orgs' + '**/*.yaml')

The plan technically succeeds, producing the desired plan output, but then atmos itself seems unhappy about the result. Looking at the pathing above, I’m running my commands from within /atmos and my atmos.yaml is located at /atmos/atmos.yaml (and I don’t define or expect any stacks to be defined within the vendored account-map module, nor do we organize based on org at our toplevel).

stacks:
  base_path: "stacks"
  included_paths:
    - "**/*"
  excluded_paths:
    - "**/_defaults.yaml"
    - "mixins/**/*"
    - "catalog/**/*"
  name_pattern: "{environment}-{stage}"

Any guidance ya’ll can provide would be tremendously helpful as to where or how to address this!