#atmos - September 2024

Hey I'm having an issue when using the github actions to apply atmos terraform where I get this error:

Error: invalid character '\x1b' looking for beginning of value
Error: Process completed with exit code 1.

the tf actually apply correctly but this error always comes up, any idea why is this happening?

this is the actions I use:
https://github.com/cloudposse/github-action-atmos-terraform-apply/tree/main

hi, have you ever considered adding Atmos plugin for asdf/mise? I think it would be useful as other tools like Terragrunt, Terramate, etc. are available within asdf plugins.

Hi. My team is leveraging github-action-terraform-plan-storage Should it also store the .terraform.lock.hcl file that gets generated as part of the plan?

Also, related to github-action-terraform-plan-storage why such an explicit check when getting the plan if a planfile already exists? I kinda expected default behavior to overwrite or at least be able to set an input var to overwrite... but maybe i'm missing something https://github.com/cloudposse/github-action-terraform-plan-storage/blob/main/src/useCases/getPlan/useCase.ts#L39-L42

Running into a fun issue this AM in where I'm getting invalid stack manifest errors. I haven't touched anything aside from trying to run one plan to test some work for next week. It started with me getting back an error that a var was defined twice in an older piece of work, which at first I'm like were these defined this way when committed and yep. The really strange thing for me though now is that it's telling me there's a variable thats already defined, but I removed it, saved it, tried to run my plan again but it says its still there.

Hey all, does anyone have experience with renaming an Atmos stack without recreating the resources. As far as I know, an Atmos stack corresponds to a Terraform workspace, so is it similar to renaming a workspace in Terraform and updating the Atmos stack name in the yaml file? I have the state in S3, so move the state/push the old workspace state to new workspace state?

Hi all. I am considering using atmos and Cloudposse root components on my new project with an existing AWS org that was created using ControlTower before I came in. So I am wondering, if it is still possible to leverage the root components and atmos in this case, and are there any examples of this setup? As I understand, the main issue will be due to usage of account/account-map/sso components. Do I need to to import the existing AWS org setup into them, or implement some replacement root components instead of account/account-map to provide account-based data to other components?

Hi CloudPosse Team
I got an issue when I enabled vpc_flow_logs_enabled: true in the quick-start-advanced lab. I also create vpc-flow-logs-bucket before.
I spend around 2 days for this issue but I can't fix it. I dont know why. Can you help me check this? Thanks.
Here is my code:

Hey I have a question about this docs:
https://atmos.tools/integrations/github-actions/atmos-terraform-drift-detection

it mentions a ./.github/workflows/atmos-terraform-plan-matrix.yaml but I don't see that anywhere dose it exist?

Hi Team
I'm using ec2-instance components for provisioning EC2 instance on AWS. But, I want to change several variables it don't appear in ec2-instance component at root like: root_volume_type, root_volume_type. How can I invoke these variables in .terraform/modules/ec2-instance/variables.tf from catalogs config. Thanks

Is there a way to hide abstract components from the atmos UI / component list?

Hi. I'm trying to us private_subnets: '{{ (atmos.Component "vpc" .stack).outputs.private_subnets }}'

And it's returning this

"private_subnets": "[subnet-00ec468ff0c78bf7c subnet-029a6827865e98783]",

expected something like

"private_subnets": [
"subnet-00ec468ff0c78bf7c",
"subnet-029a6827865e98783"
],

I suspect the template componet is doing something, with string lists, but can't figure out how to stop it

I have a stack that has some core components in it, and the stack names are based on environment: us2
namespace: dev but now we need to move this core stuff to another stack file that we will call core, the problem is that the components are already deployed and using the context ( so all the names are using namespace and environment), so I guess the only way for me to be able to move teses components without having to redeploy ( due to the name change) is to override the namespace or environment variable at the component level, but I know that is not a recommended practice, is there a better way to do this?

Hi all. I need some help to understand the difference between AWS account name and the stage and their relation. How does those two relate? Should they be identical or not? If not, then how to deal with account-map containing the AWS account names as keys in account_info_map but using the stage value to locate the necessary AWS account instead?

hey, are there any examples of using Geodesic as a container in Atmos related GitHub Actions workflows (e.g. github-action-atmos-affected-stacks)? since Geodesic (or customized image based on it) contains Atmos, Terraform, etc. I guess it could be used this way. do you see any cons with this approach?

how do you guys run this:

atmos-affected:
    runs-on: ubuntu-latest
    environment: XXXX
    permissions:
      id-token: write
      contents: read
    steps:
      - id: affected
        uses: cloudposse/github-action-atmos-affected-stacks@v3
        with:
          atmos-config-path: "./config"
          nested-matrices-count: 1
          atmos-version: 1.88.0

to use per environment credentials?

How do you gate what, and how do stacks get deployed? For example, I created PR1 for a component on dev, and after testing it is all good, now we want to deploy to prod, then I created PR2 to deploy to prod; how do I gate prod with rules? Github environments? General repo rules? I ask because in the past, I only enforced reviews, and depending on the folder using CODEOWNERS we will require different reviewers, but I was wondering if there is a better way these days

in the case of deploying things like lambdas/function apps, etc, with Atmos, how do you approach the code deployment? , do you guys add to the mono repo all the app codes and let TF deploy of the app pipelines separately from the IAC repo?

Regarding the atmos actions, what do you folks think of an atmos-version-file input similar to the setup-python’s python-version-file input?

https://github.com/cloudposse/github-action-setup-atmos/issues/97

  - name: Setup atmos
    uses: cloudposse/github-action-setup-atmos@v2
    with:
      atmos-version-file: .atmos-version

maybe an .atmos-version file ? or perhaps being able to read the asdf .tool-versions file ?

for deploying after the merge, I think I'm doing something wrong because my action is always saying that there are no changes, but the plan on the PR says otherwise, so now I wonder, when using describe affected, do I need to find the hash of the sha commit?

atmos-affected:
    if: ${{ !contains( github.event.pull_request.labels.*.name, 'no-plan') }}
    name: Determine Affected Stacks
    runs-on: ["self-hosted", "terraform"]
    steps:
      - id: affected
        uses: cloudposse/github-action-atmos-affected-stacks@v4
        with:
          atmos-version: ${{ vars.ATMOS_VERSION }}
          atmos-config-path: ${{ vars.ATMOS_CONFIG_PATH }}
          base-ref: ${{ github.event.pull_request.base.sha }}
          head-ref: ${{ github.event.pull_request.head.sha }}

I'm currently testing the GitHub actions for Atmos, and they look and work very nicely.
One thing I noticed is that they work on the apply-after-merge strategy. Is there a way to use them as apply-before-merge?

Hello! I am trying out atmos for the first time. I want to use terraform-aws-components but I encountered an issue I can't solve. I wanted to use the account and account map modules but I don't have access to the organization's root account. Is there any solution for that? I don't need to create organization or accounts just a simple vpc. Thanks for the help!

Now that my actions are running, I have questions about this settings

integrations:
  github:
    gitops:
      opentofu-version: 1.7.3  
      terraform-version: 1.5.2
      infracost-enabled: false
      artifact-storage:
        region: us-east-2
        bucket: cptest-core-ue2-auto-gitops
        table: cptest-core-ue2-auto-gitops-plan-storage

is it possible to override this settings per stack? since this is at the atmos.yaml level I do not know if they could be set per stack instead of global

I am testing out running cloudposse/github-action-atmos-terraform-plan@v3 for the first time via a manual workflow run, and I'm getting the workflow to the following point: https://github.com/cloudposse/github-action-atmos-terraform-plan/blob/main/action.yml#L118
At this point, it seems to terminate the job with "result returned successfully".
Here is my step:

      - name: Plan Atmos Component
        uses: cloudposse/github-action-atmos-terraform-plan@v3
        with:
          component: ${{ inputs.component }}
          stack: ${{ inputs.stack }}
          sha: ${{ inputs.sha }}
          atmos-version: ${{ vars.ATMOS_VERSION }}
          atmos-config-path: ${{ vars.ATMOS_CONFIG_PATH }}

Any ideas why it stops here?

I would like to expose delete protection support in the dynamodb component: https://github.com/cloudposse/terraform-aws-components/tree/main/modules/dynamodb

https://github.com/cloudposse/terraform-aws-dynamodb/blob/0.36.0/variables.tf#L184-L188

I have a branch locally, is there a process to submit these ideas for review?

another interesting issue with the actions :

atmos terraform plan github-actions -s sandbox
Error: Failed to select workspace: EOF
 exit status 1

Greetings again,

I have a question about atmos vendored terraform module versions

If I vendor a solution like this

# -------- <https://github.com/cloudposse/terraform-aws-components/tree/main/modules/lambda>
  - component: "lambda"
    source: "<http://github.com/cloudposse/terraform-aws-components.git//modules/lambda?ref={{.Version}}|github.com/cloudposse/terraform-aws-components.git//modules/lambda?ref={{.Version}}>"
    version: "1.498.0"
    targets: ["components/terraform/lambda/{{.Version}}"]
    tags:
    - lambda

This results in an import the lambda to:

components\terraform\lambda\1.498.0

In order to access use this new module, I've added the version to the component

components:
....
    lambda
      metadata:
        component: lambda/1.498.0
		

But this results in a new workspace_key_prefix for the component

{
   "terraform": {
      "backend": {
         "s3": {
...
            "workspace_key_prefix": "lambda-1.498.0"
         }
      }
   }
}

Is there a way to tell atmos to use lambda version 1.498.0 without creating a new workspace?

How do you generally approach this?