#atmos - August 2022

I have set up catalog config as shown in the s3-bucket component README.

In the actual stack file (stacks/org/prod/us-east-1.yaml), should something like this work?

(Naming replaced to match README)

components:
  terraform:
    # Temporary dev bucket in prod account
    template-bucket-dev:
      metadata:
        component: s3-bucket
        inherits:
          - template-bucket
      vars:
        stage: dev
        privileged_principal_arns:
          - arn:aws:iam::123456789123:role/eg-dev-backend-task:
              - ""
    template-bucket:
      vars:
        privileged_principal_arns:
          - arn:aws:iam::923456789123:role/eg-prod-backend-task:
              - ""

This works (as expected):
atmos terraform plan template-bucket --stack prod

This gets the error below:
atmos terraform plan template-bucket-dev --stack prod

Searched all stack files, but could not find config for the component 'template-bucket-dev' in the stack 'prod'.
Check that all variables in the stack name pattern '{stage}' are correctly defined in the stack config files.
Are the component and stack names correct? Did you forget an import?

atmos.yaml:

base_path: ""

components:
  terraform:
    base_path: "components"
    auto_generate_backend_file: true

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

logs:
  verbose: true
  colors: true

v1.4.26
what
Update versions
Fix handling of partial stacks definitions
Improve error handling
Add an example of partial stacks definition
why
Update Go, Docker, Terraform to the latest version to keep up to date
When searching for the specified component in the specified stack (e.g. atmos describe component -s ), if any of the stack config files throws error (which also means that we can't find the component in that stack), print the error to the console and continue searching for the component in...

v1.4.26
what
Update versions
Fix handling of partial stacks definitions
Improve error handling
Add an example of partial stacks definition
why
Update Go, Docker, Terraform to the latest version to keep up to date
When searching for the specified component in the specified stack (e.g. atmos describe component -s ), if any of the stack config files throws error (which also means that we can't find the component in that stack), print the error to the console and continue searching for the component in...

Hey CP folks — Not necessarily a atmos question, but in that realm around components + proces: How do you go about deleting the AWS Default VPCs?

I know about the awsutils_default_vpc_deletion (https://registry.terraform.io/providers/cloudposse/awsutils/latest/docs/resources/default_vpc_deletion), but I noticed there is no component for that resource which is what I would’ve expected to see if that was used.

cc @Matt Calhoun as I know I’ve heard you talk about this in office hours or Slack somewhere.

It would be nice to write up an article using atmos, in defense of terraform workspaces using tfvars.

For example, trussworks is vehemently against terraform workspaces and this blog post is commonly cited.

v1.4.27
what
Update atmos vendor pull
why
Allow using absolute and relative file paths in component.yaml when vendoring mixins. This will allow having mixins in a local folder (and not in a private GitHub repo for which you'll have to use a GitHub token or other means to authenticate)
# mixins override files from 'source' with the same 'filename' (e.g. 'context.tf' will override 'context.tf' from the 'source')
# mixins are processed in the order they are declared in the list
mixins:
#...

v1.4.27
what
Update atmos vendor pull
why
Allow using absolute and relative file paths in component.yaml when vendoring mixins. This will allow having mixins in a local folder (and not in a private GitHub repo for which you'll have to use a GitHub token or other means to authenticate)
# mixins override files from 'source' with the same 'filename' (e.g. 'context.tf' will override 'context.tf' from the 'source')
# mixins are processed in the order they are declared in the list
mixins:
#...

Hello, thought I'd join this slack space as I stumbled on Atmos - looks great.
Simple question though, I'm finding the complete example a bit overwhelming, does anyone have a public example that's considerably simpler that doesn't try to show all the features off?

Can atmos support a model where a stack is used as a template and you can provision multiple copies of that template where you simply change the environment prefix without having to fork/copy the yaml and make multiple stacks?

v1.4.28
what
Update atmos vendor pull
why
When pulling in mixins, override the destination file if it already exists
Prevent the error:
symlink components/terraform/mixins/context.tf components/terraform/infra/vpc-flow-logs-bucket/context.tf: file exists