#atmos - July 2022

v1.4.23
what
Fix atmos terraform clean command
Add CLI docs for atmos terraform clean command
why
atmos terraform clean command, when deleting the folder that TF_DATA_DIR points to, was using the relative path and not the component's folder. Use absolute path
atmos terraform clean is not a standard terraform command, so we need to describe it separately in the docs

v1.4.23
what
Fix atmos terraform clean command
Add CLI docs for atmos terraform clean command
why
atmos terraform clean command, when deleting the folder that TF_DATA_DIR points to, was using the relative path and not the component's folder. Use absolute path
atmos terraform clean is not a standard terraform command, so we need to describe it separately in the docs
What's Changed
Add TF_CLI_ARGS_console env var to shell subcommand by <a class="user-mention notranslate" data-hovercard-type="user"...

v1.4.24
what
Refactor stacks to the latest pattern
Refactor tests
Update everything to the latest versions
Update component processor
why
Refactor stacks in the examples to use orgs->tenants->accounts->regions + catalog and mixins - this is our latest pattern of stacks configuration
Refactor tests to reflect the new structure of the stacks folder
Use the latest versions of atmos, geodesic and terraform in the examples
Small fixes in the component processor

v1.4.24
what
Refactor stacks to the latest pattern
Refactor tests
Update everything to the latest versions
Update component processor
why
Refactor stacks in the examples to use orgs->tenants->accounts->regions + catalog and mixins - this is our latest pattern of stacks configuration
Refactor tests to reflect the new structure of the stacks folder
Use the latest versions of atmos, geodesic and terraform in the examples
Small fixes in the component processor

Kind of new to atmos and I have a question about the backend config file generation.
We’ve noticed that each time we run atmos terraform … the backend.tf.json file is generated with a different order of the keys within the s3 element.
From what I can tell it’s due to go iterating over struct keys using a random order.

I’ve created a rough test that shows this. If you run it multiple times you can see the ‘actual’ output change the ordering of the keys.

I’ve started to look at a fix but I thought I’ll ask here first as it may be something you guys can do quickly; or you can tell me a better way to deal with it.

running into this error trying to deploy the eks module (https://github.com/cloudposse/terraform-aws-eks-cluster).

Get "<https://REDACTED.us-east-1.eks.amazonaws.com/api/v1/namespaces/kube-system/configmaps/aws-auth>": getting credentials: exec plugin is configured to use API version <http://client.authentication.k8s.io/v1beta1|client.authentication.k8s.io/v1beta1>, plugin returned version <http://client.authentication.k8s.io/v1alpha1|client.authentication.k8s.io/v1alpha1>

my cluster version is 1.22

do i need to update the aws cli version in geodesic / atmos?

☝️ updated the aws cli to 2.7.14 resolved the error 🎉

@Andriy Knysh (Cloud Posse), I know this is not about the atmos strictly, but I have been able to build Docker image with atmos based on geodesic and run it.
I don't have problem with AWS session, but I have a problem with Terraform needing to authenticate against private GitLab Repo to clone underlying TF module and I need to think how to feed GitLab Personal Access Token safely to all git operations done by that container. I am targeting public Spacelift workers 1st, than if that works great I will try private EC2 workers.

Curious if people keep these in Spacelift contexts & environment typically ...

v1.4.25
what
Update component deps calculation
Add tests to check this
why
When a component defines inherited YAML base components in metadata.inherits and the stack imported the YAML file(s) where the inherited YAML components are defined, add the imported YAML files to the deps labels
Before this fix, only the base terraform component was used in the deps calculation. All imported YAML files where the base YAML components were defined were not included in the deps labels (and the YAML files were...

We’re building out a new project using atmos and I have hit the following error a few times:

Executing command:
/usr/bin/terraform plan -var-file root-account-map.terraform.tfvars.json -out root-account-map.planfile
Acquiring state lock. This may take a few moments...
╷
│ Error: stack name pattern must be provided in 'stacks.name_pattern' CLI config or 'ATMOS_STACKS_NAME_PATTERN' ENV variable
│ 
│   with module.accounts.data.utils_component_config.config,
│   on .terraform/modules/accounts/modules/remote-state/main.tf line 1, in data "utils_component_config" "config":
│    1: data "utils_component_config" "config" {
│ 
╵
Releasing state lock. This may take a few moments...
exit status 1

The first time, it was within tfstate-backend, and was resolved by not setting the access_roles variable. We’re in the middle of the cold start phase with this project.

The one above is happening with account-map and I’m not yet sure why!

I know I haven’t provided enough info but if I could get some help with debugging the cause, that would be much appreciated!

Here is the output of atmos describe config:

{
  "base_path": "",
  "Components": {
    "Terraform": {
      "base_path": "components",
      "apply_auto_approve": false,
      "deploy_run_init": true,
      "init_run_reconfigure": true,
      "auto_generate_backend_file": true
    },
    "Helmfile": {
      "base_path": "components/helmfile",
      "kubeconfig_path": "/dev/shm",
      "helm_aws_profile_pattern": "{namespace}-{tenant}-gbl-{stage}-helm",
      "cluster_name_pattern": "{namespace}-{tenant}-{environment}-{stage}-eks-cluster"
    }
  },
  "Stacks": {
    "base_path": "stacks",
    "included_paths": [
      "org/**/*"
    ],
    "excluded_paths": [
      "catalog/**/*",
      "**/_defaults.yaml"
    ],
    "name_pattern": "{stage}"
  },
  "Workflows": {
    "base_path": "workflows"
  },
  "Logs": {
    "verbose": true,
    "colors": true
  },
  "Commands": null,
  "Initialized": true
}

/cc: @Matt Gowie

I remember seeing example of multiple instances of same component in same stack possible with atmos, but having hard time finding that example now.
Anyone knows how I can achieve this?

Guys.
I’ve been trying to setup new project with atmos and after brew install atmos I’m getting

docker: Error response from daemon: pull access denied for cloudposse/atmos, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.

I tried to find that docker on docker hub but it seems to be nonexistent

is there a way to create atmos commands without having to fork the atmos repo and building a custom image?

it would be cool if i were able to add one to the atmos workspace

Hey folks — In the Component.yaml spec I believe there should be a way to specify a non-remote, local file URI, but I haven’t been able to find an example of that. Do you folks know what that looks like? I remember digging for it weeks ago and went all the way down to the go-getter code level and couldn’t figure it out in a first pass. Wanted to ask here before I went down that rabbit hole again.