#atmos - September 2022

v1.5.0
what
Add support for custom integrations in atmos.yaml
Add Atlantis support (Atlantis is an integration)
Add atmos terraform generate varfiles and atmos atlantis generate repo-config CLI commands
why
Support Atlantis
Generate the varfiles for all components in all stacks (this is used in Atlantis repo config, and will be used to detect drifts in variables to simplify triggering Spacelift stacks)
Automatically generate Atlantis repo config file atlantis.yaml. Using the config, project and...

v1.5.0
what
Add support for custom integrations in atmos.yaml
Add Atlantis support (Atlantis is an integration)
Add atmos terraform generate varfiles and atmos atlantis generate repo-config CLI commands
why
Support Atlantis
Generate the varfiles for all components in all stacks (this is used in Atlantis repo config, and will be used to detect drifts in variables to simplify triggering Spacelift stacks)
Automatically generate Atlantis repo config file atlantis.yaml. Using the config, project and...

Hey folks — I posed this question to my team the other day and would like to see if there was more specific or correct nomenclature that I’m not aware of.

We should discuss what to call an instance of a component in a stack file. My thoughts on the nomenclature right now is:

1. stack file / stack (lowercase) — The files and atmos stacks e.g. gbl-root, ue1-automation, etc.

2. Spacelift Stack / Stack (uppercase) — Spacelift’s term for an instance of a component — This has its own state and is planned / applied. e.g. ue1-audit-cloudtrail-bucket

3. Component instance (This is what I would like to have a better term for, but don’t) — The configuration in our stack files that allows us to create an instance of a component with atmos and is the local version of a “Stack”.

Any thoughts?

v1.5.1
what
Adds a --skip-init flag which allows skipping terraform init
why
This can help speed up workflows in the case that the user knows their last command successfully ran terraform init and they do not need to run init again.

v1.5.1
what
Adds a --skip-init flag which allows skipping terraform init
why
This can help speed up workflows in the case that the user knows their last command successfully ran terraform init and they do not need to run init again.

v1.6.0
what
Update atmos atlantis generate repo-config command
Support native HCL output format in atmos terraform generate varfiles command
why
Do not iterate over Go maps in atmos atlantis generate repo-config command. Go iterates over maps in a non-deterministic order resulting in constant drift in the final atlantis.yaml file. Instead, get the map keys, sort them, and iterate over the sorted keys
Support native HCL output format in atmos terraform generate varfiles command - when ejecting from...

v1.6.0
what
Update atmos atlantis generate repo-config command
Support native HCL output format in atmos terraform generate varfiles command
why
Do not iterate over Go maps in atmos atlantis generate repo-config command. Go iterates over maps in a non-deterministic order resulting in constant drift in the final atlantis.yaml file. Instead, get the map keys, sort them, and iterate over the sorted keys
Support native HCL output format in atmos terraform generate varfiles command - when ejecting from...

v1.7.0
what
Add atmos terraform generate backends command
why
Generate terraform backend configs for all terraform components
Supported formats HCL and JSON
A GitHub Action that generates all .tfvar files and backend.tf files so that projects can be used with conventional terraform GitOps tools like atlantis, Terraform Cloud, et al.
test
# hcl is default, no need to specify it
atmos terraform generate backends --format=hcl

Writing backend config for the terraform component 'test/test-component' to...

if you keep up the pace you will be in version 100.0.0 in no time

v1.7.0
what
Add atmos terraform generate backends command
why
Generate terraform backend configs for all terraform components
Supported formats HCL and JSON
A GitHub Action that generates all .tfvar files and backend.tf files so that projects can be used with conventional terraform GitOps tools like atlantis, Terraform Cloud, et al.
test
# hcl is default, no need to specify it
atmos terraform generate backends --format=hcl

Writing backend config for the terraform component 'test/test-component' to...

@PePe Amengual any opinion on using App Runner for a simpler hosting of Atlantis?

I have never used it

v1.7.1
what
Fixes an issue where ATMOS_CLI_CONFIG_PATH points to a non directory and results in a panic.
why
This provides proper messaging and gracefully fails.
The error in question here that was getting skipped over by os.IsNotExist(err) was the following:
stat /usr/local/etc/atmos/atmos.yaml/atmos.yaml: not a directory

v1.8.0
what
Remove the default hardcoded CLI config
Update TF workspace calculation for Spacelift stacks
why
Make atmos.yaml CLI config always required. Remove the default hardcoded CLI config b/c it had some default values which are not applicable for all use cases. Instead, throw error if atmos.yaml is not found
export ATMOS_LOGS_VERBOSE=true
atmos describe component test/test-component-override -s tenant1-ue2-dev

Found ENV var ATMOS_LOGS_VERBOSE=true

Searching, processing and merging atmos CLI...

Hello. Loving atmos. Hopefully a quick question on a Friday. Is there any way to have a YAML anchor in the config of an imported catalog file and then use it in your stack config?

Hey, in the latest atmos example directory structure it's been setup for multiple orgs and tenants, how is this actually used in practice?
Multiple orgs in case of organizational changes like acquisitions?
And for tenants, is this used for multi-tenant environments or even for OUs like platform and management?
I'm having trouble relating the actual example atmos setup to this SweetOps foundational infrastructure diagram.

I'm adding some CloudPosse terraform components to my atmos stacks, are the example components like this in the atmos repo following you guys' recommended pattern?
Specifically around vendoring terraform components and the context and introspection mixins, are those mixins always necessary when importing CP modules and doing things the SweetOps way?
Or maybe it's a Q for office hours?

Back again 😄
I'm stuck on an odd issue around the steps in tutorial 3, "Your first environment on AWS". I'm following the initial state setup process but on my own stacks and with the latest version of the tfstate-backend component. When running the terraform plan , atmos is looking for ../account-map/modules/ which it can't find. I tried adding the account-map component and doing an atmos vendor pull (including the modules), but still getting this error. Thread below...

@Linda Pham (Cloud Posse) let's add an internal task for @Ben Smith (Cloud Posse) or @Dan Meyers to revamp the tutorial: https://github.com/cloudposse/tutorials

@Linda Pham (Cloud Posse) has joined the channel

I'm getting a newbie error message when trying to plan a stack - I'm not really sure what I'm missing here?

pmcdonald@mt-lvt3652ckq atmos % atmos terraform plan vpc -s dev

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

.
├── ./atmos.yaml
├── ./components
│   └── ./components/terraform
│       └── ./components/terraform/vpc
│           ├── ./components/terraform/vpc/README.md
│           ├── ./components/terraform/vpc/context.tf
│           ├── ./components/terraform/vpc/main.tf
│           ├── ./components/terraform/vpc/outputs.tf
│           └── ./components/terraform/vpc/variables.tf
└── ./stacks
    ├── ./stacks/catalog
    │   └── ./stacks/catalog/terraform
    │       └── ./stacks/catalog/terraform/vpc.yaml
    └── ./stacks/dev.yaml

dev.yaml:

import:
  - catalog/terraform/vpc

vars:
  stage: dev

terraform:
  vars: {}

components:
  terraform:
    vpc:
      vars:
        enabled: true
        subnet_type_tag_key: "<http://example.net/subnet/type|example.net/subnet/type>"
        vpc_flow_logs_enabled: true
        vpc_flow_logs_bucket_environment_name: <environment>
        vpc_flow_logs_bucket_stage_name: "audit"
        vpc_flow_logs_traffic_type: "ALL"
        ipv4_primary_cidr_block: "10.111.0.0/18"

v1.8.1
what
Use namespace context variable in the code that is used to return remote-state for a component in a stack
why
For stacks config using multiple Orgs, we use namespace in stack names, and need to be able to find the remote state of the components provisioned in these stack

v1.8.1
what
Use namespace context variable in the code that is used to return remote-state for a component in a stack
why
For stacks config using multiple Orgs, we use namespace in stack names, and need to be able to find the remote state of the components provisioned in these stack

(Solved) Hey, I'm using the CloudPosse aws components for a new environment, and just tried to deploy my first component to a non-root stack, identity:

module.iam_roles.module.account_map.data.terraform_remote_state.s3[0]: Read complete after 1s
╷
│ Error: Invalid index
│
│   on ../account-map/modules/iam-roles/outputs.tf line 2, in output "terraform_role_arn":
│    2:   value = module.account_map.outputs.terraform_roles[local.account_name]
│     ├────────────────
│     │ local.account_name is "identity"
│     │ module.account_map.outputs.terraform_roles is object with 10 attributes
│
│ The given key does not identify an element in this collection value.

It's looking for the identity account in account-map instead of core-identity. Stack:

stage: identity
tenant: core
environment: gbl

In the root stack, my account component looks as follows:

.....
            - name: core
              accounts:
                - name: core-identity
                  tenant: core
                  stage: identity
                  tags:
                    eks: false
.....

and account-map:

...
        root_account_account_name: core-root
        identity_account_account_name: core-identity
...

Could this be an issue related to the null-label descriptor_formats? If so, how would I apply this special configuration of descriptor_formatsso my account-name is formatted as core-identity and not identity?

v1.8.2
what
Fix atlantis projects generation
why
apply_requirements should be under project, not under autoplan
references
https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html