Terragrunt converts: if you could have started using atmos from day one, just by doing something this in your stack configs, would that have accelerated migration/adoption?

import:
# import terragrunt units
- <terragrunt://my-terragrunt-dir/infra-live/vpc/terragrunt.hcl>
- <terragrunt://my-terragrunt-dir/infra-live/iam/terragrunt.hcl>
- <terragrunt://my-terragrunt-dir/infra-live/eks/terragrunt.hcl>

# or import a terragrunt stack
- <terragrunt://myterragrunt/infra-live/terragrunt.stack.hcl>

components:
  terraform:
    vpc:
      vars: ... anything you want to start managing in atmos
    iam:
      vars: ... anything you want to start managing in atmos
    eks:
      vars: ... anything you want to start managing in atmos

This would then get imported automatically into native atmos, and executed by atmos, not atmos calling terragrunbt. You could then systematically move things out of terragrunt, and into stack configs, or just leave it this way for legacy infra. If something doesn't work, you'd be able to continue using terragrunt because it's not changing the terragrunt configs.

@Erik Osterman (Cloud Posse) looks pretty cool. There's one thing I've noticed since we use terraform module wrappers adapted for terragrunt. With atmos, I haven't found a way to reference one item in the items collection from another. i.e:

security-groups:
  items:
    sg1:
      ...
     sg2:
       ingress_rules_with_source_security_group: 
         security_group_id: <sg1-id>

Not asking for any feature. Just something to note. We have had to split these type of components into multiple for easy

!terraform.outputs

reference

@Esteban Angee I think that's a "symptom" to how we use terragrunt-style wrappers as root modules

With atmos, I haven't found a way to reference one item in the items collection from another.

Yes, as @Jonathan Rose alludes to, we are quite opinionated against creating factories in terraform

@Erik Osterman (Cloud Posse) noted. We'll certainly have a discussions about this soon

@Erik Osterman (Cloud Posse) fun fact. @Esteban Angee and I discussed about refactoring some code we use for deploying EC2 Image Builder and removing terragrunt-style wrappers. I guess my question is how that impacts remote state configuration and how to ensure components/mixins continue to be reusable.

So moving the state out of the terraform factory will be semi pain. But the good news is you're doing it on your own terms, instead of being corned when it bites you for real. Unfortunately though, we don't provide any utilities for helping move state around at this time, so it would need to be largely "manual" using

import { ... }

blocks, loading it into a new workspace.

I am making a root terraform module to do one of two things: 1. aws_imagebuilder_component | Resources | hashicorp/aws | Terraform | Terraform Registry to create a new private component 2. aws_imagebuilder_component | Data Sources | hashicorp/aws | Terraform | Terraform Registry to store an existing (e.g. aws managed) component into remote state Here is my component (POC):

components:
  terraform:
    image-builder/component:
      backend_type: s3
      backend:
        s3:
          acl: "bucket-owner-full-control"
          encrypt: true
          key: "terraform.tfstate"
          region: "us-east-1"
          use_lockfile: true
          workspace_key_prefix: "image-builder/component"
      metadata:
        component: terraform-aws-image-builder/modules/component
      settings:
        validation:
          validate-image-builder-component-with-jsonschema:
            schema_type: jsonschema
            schema_path: "image-builder/component.json"
            description: Validate 'image-builder' component variables using JSON Schema
      vars:
        tags:
          Terraform: "cfsb/terraform-aws-modules/terraform-aws-image-builder"

Here is how I believe it should be implemented if I am understanding the use case correctly

import:
  - catalog/image-builder/component

components:
  terraform:
    cis-benchmark-level-1-amazon-linux:
      metadata:
        component: terraform-aws-image-builder/modules/component
        inherits:
          - image-builder/component
      vars:
        create: false
        name: cis-benchmark-level-1-amazon-linux
        owner: third-party
        tags:
          Purpose: "CIS Benchmark Level 1 AMI"
          Service: "ImageBuilder CIS"

but how do I ensure each item is stored correctly into remote state?

If you are relying on atmos backend generation, and it's properly configured, you don't need to do anything

OK, so I think I have a working example, but the trade-off of not using terragrunt-style wrapper means the atmos workflow would be much longer. Correct?

Not it you use

--all

or

--affected

ooooo

Here's what we use for the backend config.

backend:
    s3:
      acl: bucket-owner-full-control
      bucket: acme-core-use1-root-tfstate
      encrypt: true
      key: terraform.tfstate
      region: us-east-1
      assume_role:
        role_arn: arn:aws:iam::__ROOT_ACCOUNT_NUMBER__:role/acme-core-gbl-root-tfstate
      use_lockfile: true

I think I got a working example:

import:
  - catalog/image-builder/component

components:
  terraform:
    al2023-dnf-upgrade:
      metadata:
        component: terraform-aws-image-builder/modules/component
        inherits:
          - image-builder/component
      vars:
        create: true
        data: |
          phases:
            - name: 'build'
              steps:
                - name: 'al2023-dnf-upgrade'
                  action: 'ExecuteBash'
                  inputs:
                    commands:
                      - 'dnf upgrade --releasever=2023.9.20251117 -y' # REFS: <https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.9.20251027.html>
                      - 'dnf update && dnf upgrade -y'
                  onFailure: 'Abort'
          schemaVersion: '1.0'
        description: Upgrade AL2023 to latest package versions
        name: al2023-dnf-upgrade
        owner: self
        platform: Linux
        component_version: 2023.9.20251117
    amazon-cloudwatch-agent-linux:
      metadata:
        component: terraform-aws-image-builder/modules/component
        inherits:
          - image-builder/component
      vars:
        create: false
        name: amazon-cloudwatch-agent-linux
        owner: aws
        tags:
          Purpose: "Amazon CloudWatch Agent for Linux"
          Service: "ImageBuilder CloudWatch"
    cis-benchmark-level-1-amazon-linux:
      metadata:
        component: terraform-aws-image-builder/modules/component
        inherits:
          - image-builder/component
      vars:
        create: false
        name: cis-benchmark-level-1-amazon-linux
        owner: third-party
        tags:
          Purpose: "CIS Benchmark Level 1 AMI"
          Service: "ImageBuilder CIS"

Does this look right?

ya, we should probably add first class component and module registries that you can configure and search

oh! that looks awesome!