21 messages
👽️
Matt Gowieover 2 years ago
Anyone using Atmos with OpenTofu yet?
rssover 2 years ago(edited)
v1.48.0
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
rssover 2 years ago(edited)
v1.48.0
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
rssover 2 years ago(edited)
v1.48.0
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
what
Add overrides section to Atmos stack manifests
Update docs https://atmos.tools/core-concepts/components/overrides/
why
Atmos supports the overrides pattern to modify component(s) configuration and behavior using the overrides section in Atmos stack manifests.
You can override the following sections in the component(s) configuration:
vars
settings
env
command
The overrides section can be used at the...
Matthew Regglerover 2 years ago(edited)
Given the recent addition of passing outputs between stacks in Spacelift’s “Stack Dependencies V2” using the
This would be a way to add Terraspace/Terragrunt style stack-to-stack output sharing in the YAML without having to acquire the value “in-code” via
spacelift_stack_dependency_reference resource, has there been any thought toward adding support for this to the existing V1 support in Atmos? (https://atmos.tools/integrations/spacelift/#spacelift-stack-dependencies)This would be a way to add Terraspace/Terragrunt style stack-to-stack output sharing in the YAML without having to acquire the value “in-code” via
remote-state module use. For cases where you just want to pass in resource ARN to a downstream component’s IAM policy this would be life-changing 😍rssover 2 years ago(edited)
v1.50.0
what
Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help
why
Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies
double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...
what
Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help
why
Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies
double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...
rssover 2 years ago
v1.50.0
what
Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help
why
Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies
double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...
what
Fix processing of Spacelift stack dependencies using settings.depends_on config
Implement double-dash -- handling for terraform and helmfile commands
Update docs
Update atmos terraform --help
Update atmos helmfile --help
why
Processing of Spacelift stack dependencies using settings.depends_on config had issues with cross-environment, cross-account dependencies
double-dash -- can be used on the command line to signify the end of the options for Atmos and the start of the additional...
Guusover 2 years ago(edited)
Hi, quick question regarding
Locally this seems to works perfectly, however, in our CI/CD pipeline it fails with the following error after the terraform init happens:
Any idea on what could cause this or what I'm doing wrong here?
atmos terraform workspace <component> -s <stack>, if I understand correctly, the atmos wrapper around the workspace command should calculate the workspace, init it with -reconfigure and select it using terraform workspace select.Locally this seems to works perfectly, however, in our CI/CD pipeline it fails with the following error after the terraform init happens:
Workspace "xxx" already exists
exit status 1
Error: Atmos exited with code 1.
Error: Process completed with exit code 1.Any idea on what could cause this or what I'm doing wrong here?
Nateover 2 years ago
I am running into an issue assuming a role needed to provision dns-primary in the dns account. Here is the error:
The strange part is that there is no role by the name "hct-core-gbl-dns-terraform" in the dns account. After some digging, I realized that the the ARN of the role stored in
Here is the output from the account_map component. You can see that the role ARN includes the tenant "core".
The roles created in the
Any thoughts on what might be causing this discrepancy in role names?
Error: Cannot assume IAM Role
│
│ with provider["<http://registry.terraform.io/hashicorp/aws|registry.terraform.io/hashicorp/aws>"],
│ on providers.tf line 1, in provider "aws":
│ 1: provider "aws" {
│
│ IAM Role (arn:aws:iam::yyyyyyyyyyyy:role/hct-core-gbl-dns-terraform) cannot be assumed.
│
│ There are a number of possible causes of this - the most common are:
│ * The credentials used in order to assume the role are invalid
│ * The credentials do not have appropriate permission to assume the role
│ * The role ARN is not valid
│
│ Error: operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: cb414b0e-1fb7-4d2e-911a-de41a9db1a97,
│ api error AccessDenied: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/hct-gbl-root-admin/assumed-from-leapp is not authorized to
│ perform: sts:AssumeRole on resource: arn:aws:iam::yyyyyyyyyyyy:role/hct-core-gbl-dns-terraformThe strange part is that there is no role by the name "hct-core-gbl-dns-terraform" in the dns account. After some digging, I realized that the the ARN of the role stored in
account_map output is different from the role ARN generated as part of the assume operation in dns_primary component. Here is the output from the aws-team-roles component for the dns account. You can see that it does not contain the tenant "core".role_name_role_arn_map = {
"admin" = "arn:aws:iam::yyyyyyyyyyyy:role/hct-gbl-dns-admin"
"terraform" = "arn:aws:iam::yyyyyyyyyyyy:role/hct-gbl-dns-terraform"
}Here is the output from the account_map component. You can see that the role ARN includes the tenant "core".
terraform_roles = {
"core-artifacts" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-artifacts-terraform"
"core-audit" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-audit-terraform"
"core-dns" = "arn:aws:iam::yyyyyyyyy:role/hct-core-gbl-dns-terraform"
"core-identity" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-identity-terraform"
"core-network" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-network-terraform"
"core-root" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-root-admin"
"core-security" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-security-terraform"
"core-shared" = "arn:aws:iam::xxxxxxxxxx:role/hct-core-gbl-shared-terraform"
"plat-dev" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-dev-terraform"
"plat-prod" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-prod-terraform"
"plat-qat" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-qat-terraform"
"plat-staging" = "arn:aws:iam::xxxxxxxxxx:role/hct-plat-gbl-staging-terraform"
}The roles created in the
dns account do not include the tenant where as the assume operation is looking for a role that includes the tenant. This seems to be the pattern for output generated by aws-teams and aws-team-roles components.Any thoughts on what might be causing this discrepancy in role names?
Tyler Rankinover 2 years ago
Does
The action fails, if we change a catalog file for an in-repo component.
atmos include any way to identify “in-repo” components? We recently adopted github-action-atmos-affected-trigger-spacelift for our infrastructure monorepo, using direct triggers through spacectl. We define in-repo components in a catalog within an infrastructure monorepo, and use the spacelift component makes use of context filters to split up our spacelift admin stacks.The action fails, if we change a catalog file for an in-repo component.
atmos describe affected correctly identifies that the component’s Spacelift Stack needs to run. But it tries to trigger a spacelift run @ a particular commit SHA (from the infrastructure repo) that doesn’t exist in the repo that the Spacelift Stack actually tracks, since that project is in its own repo. If there is a way to identify these in-repo stacks, I could filter out the stack list that makes a spacectl call ahead of time.RBover 2 years ago
is there an atmos validate stacks github action ?
Erik Osterman (Cloud Posse)over 2 years ago
Erik Osterman (Cloud Posse)over 2 years ago
And some simple examples for Digital Ocean. https://github.com/leb4r/terraform-do-components
Zain Zahranover 2 years ago
Hi, I’m trying to pass a list of strings up my hierarchy through context, is there a way for me to maintain the variable type to be a string list when it goes to terraform? (Example in thread)
Bruce Edgeover 2 years ago
Hi, I'm new here. I'm on a search for a configuration mgmt tool to manage cfg for IaC and associated deployed software.
Can atmos be used solely for the configuration management aspect?
Background: I'm looking to use Gruntwork's
I still see value in atmos' cfg-mgmt component, and I'm wondering if others have used atmos solely for cfg-mgmt, in conjunction with terragrunt, and/or perhaps spacelift.
Or, perhaps have any recommendations for a (yaml based?) general purpose cfg-mgmt engine?
This IaC tooling problem is complicated enough without each tool suite growing in scope to overlap (usually in some incompatible way) with other adjacent tools.
Can atmos be used solely for the configuration management aspect?
Background: I'm looking to use Gruntwork's
live git-ops format repo with terragrunt. I particularly like their _envcommon structure to share IaC among multiple target deployments and abstract the cfg data for each. This appears to be incompatible with atmos as it also wants to the the top level owner of all root TF modules.I still see value in atmos' cfg-mgmt component, and I'm wondering if others have used atmos solely for cfg-mgmt, in conjunction with terragrunt, and/or perhaps spacelift.
Or, perhaps have any recommendations for a (yaml based?) general purpose cfg-mgmt engine?
This IaC tooling problem is complicated enough without each tool suite growing in scope to overlap (usually in some incompatible way) with other adjacent tools.
PePe Amengualover 2 years ago(edited)
I’m using atmos to deploy an ORG using the
account component and the account-map component but it looks like for the account-map component to work I have to have all the accounts defined in the stacks ( accounts created by the account component) before it can work? 🧵Christian Wabout 2 years ago
Hi everyone! I just learned about Atmos (it looks very interesting and well-architected! 👏) and I'm trying to better understand the relationship between components and stacks.
One question I have is: How does targeting a specific component within a stack work with a potentially unknown/dynamic list of component instances?
Let's say I have a "vpc"-component and I have an account ("tenant1-ue2-dev") that contains multiple instances of that component, named e.g. "vpc-1", "vpc-2" & "vpc-3".
Would I now have to deploy them separately, like this?
What if these names are not really under my control? Another account might define just one VPC, or it might use different VPC-names. I'd like to avoid needing a huge list of these
In other words, how can I ensure, all individual component instances are properly deployed to all accounts?
One question I have is: How does targeting a specific component within a stack work with a potentially unknown/dynamic list of component instances?
Let's say I have a "vpc"-component and I have an account ("tenant1-ue2-dev") that contains multiple instances of that component, named e.g. "vpc-1", "vpc-2" & "vpc-3".
Would I now have to deploy them separately, like this?
atmos terraform deploy vpc-1 --stack tenant1-ue2-dev
atmos terraform deploy vpc-2 --stack tenant1-ue2-dev
atmos terraform deploy vpc-3 --stack tenant1-ue2-devWhat if these names are not really under my control? Another account might define just one VPC, or it might use different VPC-names. I'd like to avoid needing a huge list of these
atmos terraform deploy {instance-x} --stack {stack-name} calls.In other words, how can I ensure, all individual component instances are properly deployed to all accounts?
Christian Wabout 2 years ago
Thank you for the feedback on my question from yesterday! I'd have two follow-ups, after having done some more testing:
• How do you typically handle the manual inspection/approval of plans if there is one plan per component-instance per stack and therefore potentially 10s or even 100s of plan files?
• Do you struggle with execution times in larger environments, given that there might be 10s or 100s of separate
• How do you typically handle the manual inspection/approval of plans if there is one plan per component-instance per stack and therefore potentially 10s or even 100s of plan files?
• Do you struggle with execution times in larger environments, given that there might be 10s or 100s of separate
terraform plan/apply-calls? Does atmos do anything in parallel here?Adam Markovskiabout 2 years ago(edited)
Hi folks, I don’t know if this the right place to ask this question, but here it is:
We use Atmos with Spacelift and of course this component for stack configuration. We are currently upgrading the Terraform version and trying to specify it per stack basis, sample:
However this is not picked up by Spacelift. Falling back to the default version of Terraform for the Spacelift component. What are we missing?
We use Atmos with Spacelift and of course this component for stack configuration. We are currently upgrading the Terraform version and trying to specify it per stack basis, sample:
components:
terraform:
code-artifact-repos:
metadata:
component: code-artifact
settings:
spacelift:
workspace_enabled: true
stack_destructor_enabled: false
protect_from_deletion: true
terraform_version: "1.5.7"However this is not picked up by Spacelift. Falling back to the default version of Terraform for the Spacelift component. What are we missing?