components.terraform.base_path (in atmos.yaml) doesn't support a nested directory structure - can someone confirm? I would like to organize components, at the very least, by cloud provider: /components/terraform/aws/..., but I can't get this to work.atmos describe dependents, but I'm looking for a command that operates at the stack level.v1.31.0migrations.tf style hcl but do it per component-stack so migrations-redis-banana-ue1-dev.tf wonβt be applied to redis-banana-ue2-prod!terraform.state and the component/stack you're querying for doesn't exist yet, or hasn't been applied yet?ignore_missing_template_values (link) seems to be the method @Pablo Paez found. Is there anyway to set this at a more global level than on every imported catalog ?import:
- path: "<path_to_atmos_manifest2>"
context: {}
skip_templates_processing: false
ignore_missing_template_values: truemt-prod-us, lt-prod-us-customer1)yaml
# stacks/mt/prod-us.yml
name: mt-prod-us
import:
- catalog/blueprints/mt
vars:
stage: prod
region: us-east-1
cidr_block: "1.1.1.0/24"
rds_instance_type: "db.r5.12xlarge"yaml
# catalog/blueprints/mt.yml
import:
- catalog/layers/aws/networking
- catalog/layers/aws/compute
- catalog/layers/aws/storagecidr_block: 192.168.0.0/24) in a blueprint/layer/component, but allow a top-level stack to override it?overrides.vars in the top-level stack instead of vars - seems to work in testing, but not sure if this is an anti-patternβ Warning: Incomplete lock file information for providers
β
β Due to your customized provider installation methods, Terraform was forced
β to calculate lock file checksums locally for the following providers:
β - hashicorp/aws
β - hashicorp/tls
β
β The current .terraform.lock.hcl file only includes checksums for
β linux_amd64, so Terraform running on another platform will fail to install
β these providers.
β
β To calculate additional checksums for another platform, run:
β terraform providers lock -platform=linux_amd64
β (where linux_amd64 is the platform to generate)β Warning: Version constraints inside provider configuration blocks are deprecated
β
β on providers_override.tf.json line 16, in provider.aws:
β 16: "version": "5.100.0"
β
β Terraform 0.13 and earlier allowed provider version constraints inside the
β provider configuration block, but that is now deprecated and will be
β removed in a future version of Terraform. To silence this warning, move the
β provider version constraint into the required_providers block.atmos describe components > deepmerge.yaml and the run atmos plan xyz -s ue1-dev --cached-deepmerge-yaml deepmerge.yaml or similar to save time sources:
# Vendor multiple versions of the same component
- component: vpc
source: "<http://github.com/cloudposse/terraform-aws-vpc.git///?ref={{.Version}}|github.com/cloudposse/terraform-aws-vpc.git///?ref={{.Version}}>"
targets:
- path: "vpc/{{.Version}}"
version: "2.1.0"
- path: "vpc/latest"
version: "2.2.0" Error: yaml: unmarshal errors:
line 27: cannot unmarshal !!map into string
line 29: cannot unmarshal !!map into string
line 31: cannot unmarshal !!map into string!terraform.state vs atmos.Component ? Iβm struggling to understand the differences based on the documentation.atmos.Component was breaking one of our stacks (it was causing terraform workspace to flap during plans which ultimately caused the apply step in Spacelift to fail).!terraform.state syntax instead, things began working again.catalog/component_A/defaults.yaml -> had atmos.Component templating to fetch outputs from component_Bcomponent_B -> uses remote-state module to query outputs from component_A!terraform.state syntax..workdir if the source.version has not changed