#atmos - March 2023

How can I plan or deploy the account module in the gbl region under the mgmt or core tenant in the the example within the atmos repo, when the stack name pattern is formatted as ’{tenant}-{environment}-{stage}

Hi guys, I faced to strange behavior of stacks imports.
I have 4 stacks
./atmos/stacks/backend.yaml - with some vars
./atmos/stacks/base.yaml with some vars and import

import:
- backend.yaml

`./environments/advisor/asa/backendoverlay.yaml` - with some vars
./environments/advisor/asa/newbase.yaml - with some vars and import

import:
- base

Idea is to overwrite common layer settings with environment settings - this is why stacks locates in different folders
all 4 stacks are available in `atmos describe stacks`
But when I try to modify newbase to overwrite a backend
`./environments/advisor/asa/newbase.yaml`

import:
- base
- backendoverlay

I see this error

no matches found for the import 'backendoverlay' in the file '/home/viacheslav/work/repos/helmfile-atmos/environments/advisor/asa/base.yaml'
Error: failed to find a match for the import '/home/viacheslav/work/repos/helmfile-atmos/atmos/stacks/backendoverlay.yaml' ('/home/viacheslav/work/repos/helmfile-atmos/atmos/stacks' + 'backendoverlay.yaml')```
Why Atmos looks only in one path during import, but for both during describe? Can I import anything from environments/advisor/asa/ ?

Is there a way to define a stack dependency within the stack yaml?

Hi, I was looking at atmos documentation and I noticed the command atmos vendor diff is not documented. Also some other things:

I feel one of the core parts of the atmos experience is reusing open source code which is great, but the way things are "vendored" in using a git clone at a point in time and changes being made via mixins, otherwise a vendor pull will silently overwrite your changes - this makes it very hard to upstream. I know any change to atmos in this area is likely a large architectural change, but if components were somehow vendored in as git submodules, or in some way that would enable us to use existing tooling to maintain changes against upstream, that would help to foster upstreaming/contribution

and third, would you consider decoupling the terraform command apply, plan, from the atmos terraform command?

I would rather do atmos terraform -c component -s stack plan because then it feels more that atmos will explicitly pass everything after the stack to terraform. when it is atmos terraform plan -c .. -s .. then i wonder what atmos is doing under the hood, if they truly support every terraform command (including future commands if atmos is not updated)

a minor UX nitpick that I have learned to live with but was confusing at first

Also regarding stacks - is there any plan to give the ability at the atmos level to retrieve outputs from one stack to be passed as inputs to another stack? I prefer to never use remote_state references in native terraform, I come from a terragrunt world where dependencies' outputs can be transformed into inputs easily, and that's something I'm missing

hey all 👋 is there a way to specify Terraform provider/version information in a stack file? In particular I'd like to configure the TF Kubernetes provider with the correct context without having to pass it in as a variable (e.g. generating a providers.tf.json the same way atmos can generate backend.tf.json).

Cross posting here: https://sweetops.slack.com/archives/CB6GHNLG0/p1678373778144549

atmos terraform output -s path/to/stack component -json doesn't work, atmos seemingly interprets the -js and looks for a stack called "on"

hi, could someone please tell me what this tool he's using for authenticating? https://youtu.be/0dFEixCK0Wk?t=2525

v1.31.0
what
Fix an issue when the terraform components were in subfolders in the components/terraform folder deeper than the second level
Add atmos describe dependants command
Update docs
why

Fix an issue when the terraform components were in subfolders in the components/terraform folder deeper than second level. For example:
https://user-images.githubusercontent.com/7356997/224600584-d77e3fe6-a7a4-4d6d-a691-7cd2a5603963.png
The...

v1.31.0
what
Fix an issue when the terraform components were in subfolders in the components/terraform folder deeper than the second level
Add atmos describe dependants command
Update docs
why

Fix an issue when the terraform components were in subfolders in the components/terraform folder deeper than second level. For example:
https://user-images.githubusercontent.com/7356997/224600584-d77e3fe6-a7a4-4d6d-a691-7cd2a5603963.png
The...

my-ecs-service inherits ecs-service/with-lb inherits ecs-service/default.

This doesn't work unless in my-ecs-service I also add an inherits line for ecs-service/default. It would seem if I inherit something, I also inherit what it inherits.

Is this the expected functionality? Could this apply the deep merge on inheritance like it does for other parts?

NOTE: I get that this is an array so YAML arrays aren't merged so I'm asking if something else could be done here.

YAML example:

components:
  terraform:
    my-ecs-service:
      metadata:
        component: ecs-service
        inherits:
          - ecs-service/with-lb

--

components:
  terraform:
    ecs-service/with-lb:
      metadata:
        component: ecs-service
        inherits:
          - ecs-service/default
        type: abstract

--

components:
  terraform:
    ecs-service/default:
      metadata:
        component: ecs-service
        type: abstract

A quick question about atmos vendor pull authentication. Currently go-getter supports basic and headers authentication for http(s) sources https://github.com/hashicorp/go-getter/blob/main/README.md#http-http. But I didn't found something about it in Atmos vendor utils: https://github.com/cloudposse/atmos/blob/c1679524cf66d241e0426672bfadbee6447aed69/internal/exec/vendor_utils.go#L196
Does Atmos support any kind of authentication for vendors? In my case I need to authenticate on JFrog Artifactory (both basic and header auth supported) to download a zip with component.

So for replacing values in a stack yaml is shown on https://atmos.tools/core-concepts/stacks/imports.

it isn't working for me on v1.31.0. Do we have to use path/context on the import for it to work? (meaning it can't read the values without being pushed those values)

yaml:

...
            map_environment:
              AWS_ENV: "{{ .stage }}"
            map_secrets:
              NEW_RELIC_LICENSE_KEY: "/{{ .stage }}/newrelic/license_key"
...

describe component:

      map_environment:
        APP_NAME: report-generator
        AWS_ENV: '{{ .stage }}'
        NEW_RELIC_DISTRIBUTED_TRACING_ENABLED: true
        NEW_RELIC_ENABLED: true
      map_secrets:
        NEW_RELIC_LICENSE_KEY: /{{ .stage }}/newrelic/license_key

context: all non-prod (6-8 accounts) uses 1 value and prod has a different value.

For the Go template imports, is there a good way to provide a default value?

I'd like to not have to copy the value 6-8 times and would prefer to provide a default value then just override in prod the 1 time.

I have to copy this N times and tweak for prod right now:

  - path: "ssm-parameters-tmpl"
    context:
      license_path: nonprod.xml

I could prob do abstract versions then just inherit the default and override specifics. A simpler version in 1 file would be ideal.

possible options (in the tmpl file):

context:
  defaults:
    license_path: nonprod.xml

...or inline...

"/{{ .stage }}/license/path":
  value: "{{ .license_path | nonprod.xml}}"
  description: iText license path
  overwrite: true
  type: String

The difference with the former is it allows a DRY solution in case a value is needed multiple times. Support for both would be ideal.

Thoughts @Andriy Knysh (Cloud Posse)?

Go templates in atmos stacks are a game changer! 🔥

v1.32.0
what
Add Hierarchical Inheritance and Multilevel Inheritance for Atmos Components
Update docs https://atmos.tools/core-concepts/components/inheritance
why
Allow creating complex hierarchical stack configurations and make them DRY
In Hierarchical Inheritance, every component can act as a base component for one or more child (derived) components, and each child component can inherit from one of more base...

v1.32.1
what
Update atmos describe affected command
why
Handle atmos absolute base path when working with the cloned remote repo in the describe affected command
Absolute base path can be set in the base_path attribute in atmos.yaml, or using the ENV var ATMOS_BASE_PATH (as it's done in geodesic)
If the atmos base path is absolute, find the relative path between the local repo path and the atmos base path. This relative path (the difference) is then used to join with the remote (cloned) repo path

v1.32.1
what
Update atmos describe affected command
why
Handle atmos absolute base path when working with the cloned remote repo in the describe affected command
Absolute base path can be set in the base_path attribute in atmos.yaml, or using the ENV var ATMOS_BASE_PATH (as it's done in geodesic)
If the atmos base path is absolute, find the relative path between the local repo path and the atmos base path. This relative path (the difference) is then used to join with the remote (cloned) repo path

is there a plan to add in graphviz or similar support to map out component connections, @Andriy Knysh (Cloud Posse)?

v1.32.2
what & why
Converted 'Get Help' nav bar item to CTA button
More user friendly 404 page

v1.32.2
what & why
Converted 'Get Help' nav bar item to CTA button
More user friendly 404 page

v1.32.3
what & why
Use consolidated search index between atmos.tools and docs.cloudposse.com #351
Fix panic on "index out of range" in terraform two-words...

v1.32.3
what & why
Use consolidated search index between atmos.tools and docs.cloudposse.com #351
Fix panic on "index out of range" in terraform two-words...

v1.32.4
what
Update atmos describe affected command
why
Check if not only the files in the component folder itself have changed, but also the files in all sub-folders at any level
test
For example, if we have the policies sub-folder in the component folder components/terraform/top-level-component1, and we have some files in the sub-folder (e.g. components/terraform/top-level-component1/policies/policy1.rego), and if the files changed, atmos describe affected would mark all Atmos components that use...

v1.32.4
what
Update atmos describe affected command
why
Check if not only the files in the component folder itself have changed, but also the files in all sub-folders at any level
test
For example, if we have the policies sub-folder in the component folder components/terraform/top-level-component1, and we have some files in the sub-folder (e.g. components/terraform/top-level-component1/policies/policy1.rego), and if the files changed, atmos describe affected would mark all Atmos components that use...

Is there a good way to read the component name of a stack from within that component? For example I need what is the equivalent of TF_VAR_spacelift_stack_id from here but in a local run

so I have this

block_device_mappings: 
        - device_name: "/dev/sda1"
          no_device: false
          virtual_name: null
          ebs: 
            volume_size: 20
            delete_on_termination: true
            encrypted: true
            volume_type: "gp2"
            iops: null
            kms_key_id: null
            snapshot_id: null

in a type: abstract component and then I use it like so:

lol

@Zach B has joined the channel

Is it possible for atmos to generate backend files when the backend uses blocks?

E.g.:

terraform {
  backend "remote" {
    hostname = "<http://app.terraform.io|app.terraform.io>"
    organization = "company"

    workspaces {
      prefix = "my-app-"
    }
  }
}

How can the workspaces block be included with YAML?:

---
terraform:
  backend_type: remote
  backend:
    remote:
      organization: company
      hostname: <http://app.terraform.io|app.terraform.io>

trying to take a look at atmos for our environment... we're already using many cloudposse Terraform modules for our new deployments so looking to see how easily I can migrate things over to using atmos