#atmos - June 2024

Hey, I’m using atmos with Azure, and I noticed the github-action-atmos-terraform-plan and github-action-atmos-terraform-apply github actions are AWS specific. Would a PR be welcome to allow them to work with Azure too?

Hey all, wondering if there is a way to set a workspace pattern override at the top level configuration in a stack file. Similar to this idea in the docs (https://atmos.tools/core-concepts/components/terraform-workspaces/#terraform-workspace-override-in-atmos) but that's for an individual, if there's a more efficient way to apply it to all in that stack YAML file.

For context, the reason is that the resources is managed via Spacelift and we have a stack_name_pattern (https://github.com/cloudposse/atmos/releases/tag/v1.4.1) override (which is on the top level) for this particular file but unless there is a workspace override, the naming becomes inconsistent.

hi, i've modified atmos schema.json to support "assume_role" in s3 backend. Maybe you want to add it to the schema definition:

M stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json
@@ -498,6 +498,14 @@
"region": {
"type": "string"
},
+ "assume_role": {
+ "role_arn": {
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
"role_arn": {
"type": [
"string",

It would be nice to not have to redefine every modules' inputs in the component. This github comment on using a provider function to decode_tfvars and then pass it into modules would prevent having to define each var in each component

I’ve been wrangling with the best way to implement resource groups in Azure. Initially I created a storage component that provisions storage resources in a resource group (also created by the storage component). This worked great - the component would (by default) create a resource group for each component, or, I could provide a resource group name and it would re-use an existing resource group.

Then I realized because I’m deploying atmos component changes in parallel using a matrix in my pipeline, the ordering of resource creation is important, and reusing another resource group can fail if it hasn’t already been created.

So I experimented with using a data in the storage component to check if a resource group is missing and create it if it is. But then de-provisioning blows up when destroying the storage component that created the resource group because it still contains other resources.

I’ve since created a resourcegroups component which accepts a list of resource group names from the stack yaml, and provisions them, but again - if this component isn’t deployed first by the pipeline, deploying other components will fail. Is that the right way to do this?

Has anyone else solved this conundrum? (Thanks)

Sharing some Atmos + Cloud Posse component love 🚀

Hi everyone,
I am trying to configure gcs backend for GCP deployment. Does remote-state module support gcs as backend ?

question: how can i use object in vars:

this is working

component:
    server:
       vars:
        hc_ssh_keys:
          shelas:
            name: foo
            filename: bar

but this ist not

settings:
   ssh_keys:
       shelas:
           name: foo
           filename: bar


component:
    server:
       vars:
        hc_ssh_keys: '{{ .settings.ssh_keys }}'

Hi 👋
I'm super new to Atmos so excuse the question, but I couldnt seem to find an answer from searching and my assumptions may be wrong.

From my understanding Atmos works by defining name_pattern: "{tenant}-{stage}-{environment}", and essentially each stack needs to supply these vars in order for it to work.

This is done by adding to a relevant yaml to the stack/mixin.

vars:
  environment: west-us-2
  stage: dev
  tenant: plat

My question is whether or not we can define these values outside of the vars: key?
The Terraform modules I'm using do not have these variables defined, which is leading to a bunch of Value for undeclared variable whenever I run a Terraform plan/apply.

If I can move these outside of the vars: key, then they wont be passed into the generated .tfvars.json and I wont get the error from Terraform.

Thanks!

Is there an example or a GitHub demo repo that plumbs atmos in argocd . Would like to give a try on how atmos can execute atmos plan/apply? Would it be a substitute of spacelift like system or Argo cd is just for helmfile?

Any thoughts about supporting imports at a component level rather than stack level? Example - I have 1 stack (a management group in azure) that has 3 subscriptions (eng, test, prod). And i have mixins for each "environment" eng/test/prod. I want to import the particular mixin w/ the particular subscription within the same stack

Newbie here,
After setting an account structure using the account component on the core tenant, I'm trying to create an EKS cluster on one of the accounts that have been created. I'm getting the following error:

│ Error: Reference to undeclared module
│
│   on main.tf line 7, in locals:
│    7:   this_account_name = module.iam_roles.current_account_account_name
│
│ No module call named "iam_roles" is declared in the root module.

Seems like the eks/cluster component is referencing iam_roles (a sub module of account-info) without actually adding it as a module in the TF eks/cluster module

What do I miss?

hey all - working with module ec2-instance, specifically cloudpossee/security-group/aws - my issue is that I'm trying to configure the rule as a security group ingress versus cidr_block. now I see online it says source_security_group_id can be configured, but it is not liking that in my testing. I can work around this otherwise but figured I'd ask here first.

Hi all. Did not found proper issue or conversation about it. I notice a difference in atmos generate backends and atmos generate backend %component% behaviors. Templating is not respected by backends. Is it intentional?

Hi, I'm testing out atmos v1.81 template functions release:
How do I get array element for this one?

- '{{ (atmos.Component "aws-vpc" .stack).outputs.private_subnets }}'

New docs are live! This is a massive update that includes:
• New demos (including with k3s and localstack)
• Simple quick start - https://atmos.tools/quick-start/simple/
• Devcontainer - https://github.com/codespaces/new?hide_repo_select=true&ref=main&repo=cloudposse/atmos&skip_quickstart=true
• Localstack - https://github.com/cloudposse/atmos/tree/main/examples/demo-localstack
• The "Atmos Mindset" https://atmos.tools/quick-start/mindset

How does one verify the pr is approved by a codeowner before allowing atmos apply within a PR ?

How does one prevent atmos apply of components and stacks outside of the atmos PR’s file changes?

Also regarding the drift detection on github issues, how does one only allow specific users (such as codeowners) to allow commenting to apply those stacks ?

When using the atmos.Component template functions for retrieving a few component outputs, I’ve noticed a slow down when running a terraform plan or terraform apply or even just running atmos itself, the startup is quite delayed. Just wondering if that is expected, since I guess the more outputs that are pulled this way, the more state lookups are needed?