#atmos - November 2023

Anyone using Atmos with OpenTofu yet?

v1.48.0
what

Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/

why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:

vars
settings
env
command

The overrides section can be used at the...

v1.48.0
what

Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/

why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:

vars
settings
env
command

The overrides section can be used at the...

v1.48.0
what

Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/

why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:

vars
settings
env
command

The overrides section can be used at the...

v1.49.0
what

Update depends_on and atmos describe dependents
Restore checking for the context in imports with Go templates removed in #464
Update README

why...

v1.49.0
what

Update depends_on and atmos describe dependents
Restore checking for the context in imports with Go templates removed in #464
Update README

why...

Given the recent addition of passing outputs between stacks in Spacelift’s “Stack Dependencies V2” using the spacelift_stack_dependency_reference resource, has there been any thought toward adding support for this to the existing V1 support in Atmos? (https://atmos.tools/integrations/spacelift/#spacelift-stack-dependencies)

This would be a way to add Terraspace/Terragrunt style stack-to-stack output sharing in the YAML without having to acquire the value “in-code” via remote-state module use. For cases where you just want to pass in resource ARN to a downstream component’s IAM policy this would be life-changing 😍

v1.50.0
what

Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help

why


Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies


double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...

v1.50.0
what

Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help

why


Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies


double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...

Hi, quick question regarding atmos terraform workspace <component> -s <stack>, if I understand correctly, the atmos wrapper around the workspace command should calculate the workspace, init it with -reconfigure and select it using terraform workspace select.

Locally this seems to works perfectly, however, in our CI/CD pipeline it fails with the following error after the terraform init happens:

Workspace "xxx" already exists
exit status 1

Error: Atmos exited with code 1.
Error: Process completed with exit code 1.

Any idea on what could cause this or what I'm doing wrong here?

I am running into an issue assuming a role needed to provision dns-primary in the dns account. Here is the error:

Error: Cannot assume IAM Role
│ 
│   with provider["<http://registry.terraform.io/hashicorp/aws|registry.terraform.io/hashicorp/aws>"],
│   on providers.tf line 1, in provider "aws":
│    1: provider "aws" {
│ 
│ IAM Role (arn:aws:iam::yyyyyyyyyyyy:role/hct-core-gbl-dns-terraform) cannot be assumed.
│ 
│ There are a number of possible causes of this - the most common are:
│   * The credentials used in order to assume the role are invalid
│   * The credentials do not have appropriate permission to assume the role
│   * The role ARN is not valid
│ 
│ Error: operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: cb414b0e-1fb7-4d2e-911a-de41a9db1a97,
│ api error AccessDenied: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/hct-gbl-root-admin/assumed-from-leapp is not authorized to
│ perform: sts:AssumeRole on resource: arn:aws:iam::yyyyyyyyyyyy:role/hct-core-gbl-dns-terraform

The strange part is that there is no role by the name "hct-core-gbl-dns-terraform" in the dns account. After some digging, I realized that the the ARN of the role stored in account_map output is different from the role ARN generated as part of the assume operation in dns_primary component. Here is the output from the aws-team-roles component for the dns account. You can see that it does not contain the tenant "core".

role_name_role_arn_map = {
  "admin" = "arn:aws:iam::yyyyyyyyyyyy:role/hct-gbl-dns-admin"
  "terraform" = "arn:aws:iam::yyyyyyyyyyyy:role/hct-gbl-dns-terraform"
}

Here is the output from the account_map component. You can see that the role ARN includes the tenant "core".

terraform_roles = {
  "core-artifacts" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-artifacts-terraform"
  "core-audit" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-audit-terraform"
  "core-dns" = "arn:aws:iam::yyyyyyyyy:role/hct-core-gbl-dns-terraform"
  "core-identity" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-identity-terraform"
  "core-network" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-network-terraform"
  "core-root" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-root-admin"
  "core-security" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-security-terraform"
  "core-shared" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-shared-terraform"
  "plat-dev" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-dev-terraform"
  "plat-prod" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-prod-terraform"
  "plat-qat" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-qat-terraform"
  "plat-staging" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-staging-terraform"
}

The roles created in the dns account do not include the tenant where as the assume operation is looking for a role that includes the tenant. This seems to be the pattern for output generated by aws-teams and aws-team-roles components.

Any thoughts on what might be causing this discrepancy in role names?

Does atmos include any way to identify “in-repo” components? We recently adopted github-action-atmos-affected-trigger-spacelift for our infrastructure monorepo, using direct triggers through spacectl. We define in-repo components in a catalog within an infrastructure monorepo, and use the spacelift component makes use of context filters to split up our spacelift admin stacks.

The action fails, if we change a catalog file for an in-repo component. atmos describe affected correctly identifies that the component’s Spacelift Stack needs to run. But it tries to trigger a spacelift run @ a particular commit SHA (from the infrastructure repo) that doesn’t exist in the repo that the Spacelift Stack actually tracks, since that project is in its own repo. If there is a way to identify these in-repo stacks, I could filter out the stack list that makes a spacectl call ahead of time.

is there an atmos validate stacks github action ?

And some simple examples for Digital Ocean. https://github.com/leb4r/terraform-do-components

Hi, I’m trying to pass a list of strings up my hierarchy through context, is there a way for me to maintain the variable type to be a string list when it goes to terraform? (Example in thread)

Hi, I'm new here. I'm on a search for a configuration mgmt tool to manage cfg for IaC and associated deployed software.
Can atmos be used solely for the configuration management aspect?
Background: I'm looking to use Gruntwork's live git-ops format repo with terragrunt. I particularly like their _envcommon structure to share IaC among multiple target deployments and abstract the cfg data for each. This appears to be incompatible with atmos as it also wants to the the top level owner of all root TF modules.
I still see value in atmos' cfg-mgmt component, and I'm wondering if others have used atmos solely for cfg-mgmt, in conjunction with terragrunt, and/or perhaps spacelift.
Or, perhaps have any recommendations for a (yaml based?) general purpose cfg-mgmt engine?
This IaC tooling problem is complicated enough without each tool suite growing in scope to overlap (usually in some incompatible way) with other adjacent tools.

I’m using atmos to deploy an ORG using the account component and the account-map component but it looks like for the account-map component to work I have to have all the accounts defined in the stacks ( accounts created by the account component) before it can work? 🧵

Hi everyone! I just learned about Atmos (it looks very interesting and well-architected! 👏) and I'm trying to better understand the relationship between components and stacks.

One question I have is: How does targeting a specific component within a stack work with a potentially unknown/dynamic list of component instances?

Let's say I have a "vpc"-component and I have an account ("tenant1-ue2-dev") that contains multiple instances of that component, named e.g. "vpc-1", "vpc-2" & "vpc-3".

Would I now have to deploy them separately, like this?

atmos terraform deploy vpc-1 --stack tenant1-ue2-dev
atmos terraform deploy vpc-2 --stack tenant1-ue2-dev
atmos terraform deploy vpc-3 --stack tenant1-ue2-dev

What if these names are not really under my control? Another account might define just one VPC, or it might use different VPC-names. I'd like to avoid needing a huge list of these atmos terraform deploy {instance-x} --stack {stack-name} calls.

In other words, how can I ensure, all individual component instances are properly deployed to all accounts?

Thank you for the feedback on my question from yesterday! I'd have two follow-ups, after having done some more testing:

• How do you typically handle the manual inspection/approval of plans if there is one plan per component-instance per stack and therefore potentially 10s or even 100s of plan files?
• Do you struggle with execution times in larger environments, given that there might be 10s or 100s of separate terraform plan/apply-calls? Does atmos do anything in parallel here?

Hi folks, I don’t know if this the right place to ask this question, but here it is:
We use Atmos with Spacelift and of course this component for stack configuration. We are currently upgrading the Terraform version and trying to specify it per stack basis, sample:

components:
  terraform:
    code-artifact-repos:
      metadata:
        component: code-artifact
      settings:
        spacelift:
          workspace_enabled: true
          stack_destructor_enabled: false
          protect_from_deletion: true
          terraform_version: "1.5.7"

However this is not picked up by Spacelift. Falling back to the default version of Terraform for the Spacelift component. What are we missing?