#atmos - June 2023

Hello, Im running into this error when trying to apply a stack that uses cloudposse/terraform-aws-ecs-cluster

│ Error: Unsupported attribute
│ 
│   on .terraform/modules/autoscale_group/outputs.tf line 23, in output "autoscaling_group_tags":
│   23:   value       = module.this.enabled ? aws_autoscaling_group.default[0].tags : []
│ 
│ This object has no argument, nested block, or exported attribute named "tags". Did you mean "tag"?

Hello there, I'm trying out the tutorial here: https://atmos.tools/tutorials/first-aws-environment but atmos terraform apply tfstate-backend --stack ue2-root outputs:

tfstate_backend_dynamodb_table_name = "acme-ue2-root-tfstate-delicate-elf-lock"
tfstate_backend_s3_bucket_arn = "arn:aws:s3:::acme-ue2-root-tfstate-delicate-elf"

while atmos terraform generate backend tfstate-backend --stack ue2-root generates:

   "bucket": "acme-ue2-tfstate-delicate-elf",
   "dynamodb_table": "acme-ue2-tfstate-lock-delicate-elf",

After I edit the backend.tf.json file to match the correct resource names, it succeeds migrating state to S3.

But continuting to deploy the static site, I get

Workspace "uw2-dev" doesn't exist.

I'm probably doing something very wrong, but I cannot figure out what 😄

Hi, I am a bit confused by something the example stack, and some of the docs for the modules. Say I have the account module deployed in a stack (gbl-root):

components:
  terraform:
    "infra/account":
      metadata:
        component: infra/account

(thread to follow...)

is there a way to reference values inside of atmos yet?

I’m trying to use : https://atmos.tools/core-concepts/stacks/imports#go-templates-in-imports and I get an error

Which file or for that matter where does one set the {tenant}-{environment}-{stage}. Where do I set the tenant or the environment or the stage

Is there a way to see what they are currently set to ?

If I want to pass in the backend option specifically the key on each stack that is built is there a simple way to do that. Specifically I have some default backend option and I want to add the key element to that backend configuration at each stack or better yet have it included in as part of the run. Would I use the include option for the stack or would I use mixins. Also when the yaml is merged can I give a strategy to say I want to merge or overwrite ? does this make sense

define in the some file that is included
backend:
s3:
bucket: "somebucket"
region: "someregion"
encrypt: true
dynamodb_table: "somelocktable"
kms_key_id: "somerole"
The in the stack have something like
backend:
s3:
key: "somekey"

then the merged dict would include both

A few more questions around the import statements that are at the top is there a way to template them. ?
I have
import:
- org/dvsa/_defaults
- org/dvsa/dev/_defaults

What I want to do is make this generic so it can be picked up by default based on the vars I have set
something along the lines of
import:
- org/_defaults
- org/{tenant}/_defaults
- org/{tenant}/{namespace}/{app_region}/_defaults
- org/{tenant}/{namespace}/{app_region}/{environment}/_defaults

So the later defaults an override the ones that came before it if they so wish but not be explicit in defining them.

So I have a multiple orgs so we abstract what is common in all orgs into the __default,yaml at that level. The we have for each org we define the _default.yaml at that level then I have a logical app_region one of "dev,uat,prd" at that level there is a _default.yaml that is common across all dev environments then I have multiple environments which all have their own defaults.yaml which then can be merged in to the components which can override them at the environment level or add depending on what is needed. Or is there a different way to implement what I need to do ?

I fear this is a dumb question -
For the Atmos quickstart, are you supposed to work completely out of the sample _repo_? I’m at the Create Components section of the quick start and atmos vender pull --component infra/vpc
I get this error

failed to find a match for the import '/Users/johnfahl/blah/terraform-atmos-learn/stacks/orgs/**/*.yaml'

I basically made a new repo, create the stacks and components folders and added the yaml files for vpc and vpc-flow-control-logs as instructed and was going to pull the component directories down.
I feel I could probably fix this by grabbing the entire example repo and work out of that, but I thought the quick start would guide the build out more from scratch.
Any help would be great (edited)

v1.36.0
what
Add timeout parameter to atmos validate component command
Add timeout parameter to settings.validation section in the stack config
Update docs
why

If validation is configured for a component, Atmos executes the configured OPA Rego policies. If a policy is misconfigured (e.g. invalid Rego syntax or import), the validation can take a long time and eventually fail. Use the --timeout parameter to specify the required timeout


The timeout (in seconds) can be specified on the command line:...

v1.36.0
what
Add timeout parameter to atmos validate component command
Add timeout parameter to settings.validation section in the stack config
Update docs
why

If validation is configured for a component, Atmos executes the configured OPA Rego policies. If a policy is misconfigured (e.g. invalid Rego syntax or import), the validation can take a long time and eventually fail. Use the --timeout parameter to specify the required timeout


The timeout (in seconds) can be specified on the command line:...

has anyone migrated a stack from an older implementation of atmos (implemented a little over a year ago) to the latest?

Hi guys,
Is there any who can help me to do atmos vendor pull in scp-style?

# Questions
Hi, When I do vendor pull with atmos cli to use ssh to clone the code, but it fails.
It works when I configure the uri with http protocol but fails with url-style or scp-style.

Here is the component description I have:

apiVersion: atmos/v1
kind: ComponentVendorConfig
metadata:
  name: bucket
  description: A bucket to build
spec:
  source:
    uri: <http://github.com/cloudposse/terraform-aws-ec2-instance.git///?ref={{.Version}}|github.com/cloudposse/terraform-aws-ec2-instance.git///?ref={{.Version}}> # working
    # uri: <mailto:git@github.com|git@github.com>/cloudposse/terraform-aws-ec2-instance.git?ref={{.Version}} # case 1 - not working
    # uri: git::<ssh://git@github.com/cloudposse/terraform-aws-ec2-instance.git?ref={{.Version}}> # case 2 - not working
    version: 0.47.1

This is the error message I got.
# case 1

root@075977a85269:/atmos# atmos vendor pull -c infra/bucket
Pulling sources for the component 'infra/bucket' from '<mailto:git@github.com|git@github.com>/cloudposse/terraform-aws-ec2-instance.git?ref=0.47.1' and writing to 'components/terraform/infra/bucket'

relative paths require a module with a pwd

# case 2

root@075977a85269:/atmos# atmos vendor pull -c infra/bucket
Pulling sources for the component 'infra/bucket' from 'git::<ssh://git@github.com/cloudposse/terraform-aws-ec2-instance.git?ref=0.47.1>' and writing to 'components/terraform/infra/bucket'

error downloading '<ssh://git@github.com/cloudposse/terraform-aws-ec2-instance.git?ref=0.47.1>': /usr/bin/git exited with 128: fatal: not a git repository (or any of the parent directories): .git

Please help me out to pull Terraform modules with atmos. Thank you in advance.

v1.37.0
what
Add spacelift_stack and atlantis_project outputs to atmos describe component command
Add --include-spacelift-admin-stacks flag to atmos describe affected command
Update Atmos docs
why

Having the spacelift_stack and atlantis_project outputs from the atmos describe component command is useful when using the command in GitHub actions related to Spacelift and Atlantis


The --include-spacelift-admin-stacks flag for the atmos describe affected command allows including the Spacelift admin...

v1.37.0
what
Add spacelift_stack and atlantis_project outputs to atmos describe component command
Add --include-spacelift-admin-stacks flag to atmos describe affected command
Update Atmos docs
why

Having the spacelift_stack and atlantis_project outputs from the atmos describe component command is useful when using the command in GitHub actions related to Spacelift and Atlantis


The --include-spacelift-admin-stacks flag for the atmos describe affected command allows including the Spacelift admin...

I can see in this file "https://github.com/cloudposse/atmos/blob/master/examples/complete/stacks/orgs/cp/tenant1/dev/us-east-2.yaml" which I think is a stack that you make use of this construct

name: "{tenant}-{environment}-{stage}-{component}"

Which are not template variables what are these and where do they come from can they be used anywhere ?

in the same file I also see

{ workflow }

any known usage of Atmos on TFC?

Hello, I'm trying to use remote-state.tf and I'm getting this error, any clues how to solve this?

Error: failed to find a match for the import '/Users/pmcdonald/workspace/atmos-metrop/components/terraform/transfer-sftp/stacks/orgs/**/*.yaml' ('/Users/pmcdonald/workspace/atmos-metrop/components/terraform/transfer-sftp/stacks/orgs' + '**/*.yaml')
│ 
│ 
│ CLI config:
│ 
│ base_path: ""
│ components:
│   terraform:
│     base_path: components/terraform
│     apply_auto_approve: false
│     deploy_run_init: true

v1.38.0
what
Refactor Atmos components validation with OPA
Allow creating a catalog of reusable Rego modules, constants and helper functions to be used in OPA policies
Update docs
why
Atmos supports OPA policies for component validation in a single Rego file and in multiple Rego files.
As shown in the example below, you can define some Rego constants, modules and helper functions in a separate
file stacks/schemas/opa/catalog/constants/constants.rego, and then import them into the main policy
file...

v1.38.0
what
Refactor Atmos components validation with OPA
Allow creating a catalog of reusable Rego modules, constants and helper functions to be used in OPA policies
Update docs
why
Atmos supports OPA policies for component validation in a single Rego file and in multiple Rego files.
As shown in the example below, you can define some Rego constants, modules and helper functions in a separate
file stacks/schemas/opa/catalog/constants/constants.rego, and then import them into the main policy
file...

Just revisited atmos and looking forward to exploring the latest. Didn’t realize it was written in Go