cloudposse / atmos

👽 Terraform Orchestration Tool for DevOps. Keep environment configuration DRY with hierarchical imports of configurations, inheritance, and WAY more. Native support for Terraform and Helmfile.
https://atmos.tools
Apache License 2.0
806 stars 97 forks source link

Able to alias stack name conventions #581

Open nitrocode opened 7 months ago

nitrocode commented 7 months ago

Describe the Feature

I like using ue1-dev or org-ue1-dev, but it would be nice to alias them

so then we could have

ue1-dev         # this is real so env = ue1, stage = dev
ue1-development # alias to the above
ue1-dev-01      # alias to the above

Expected Behavior

atmos terraform plan s3-bucket/test --stack ue1-dev
atmos terraform plan s3-bucket/test --stack ue1-development
atmos terraform plan s3-bucket/test --stack ue1-dev-01

Use Case

Easier for devs to use older account names that may not match the shortest stage names

Existing account names can be too long where if they were used as stage then aws resources are more likely to hit max character restraints

Describe Ideal Solution

See above

Alternatives Considered

No response

Additional Context

No response

osterman commented 7 months ago

That's an interesting use-case. Let me take my spin, use names that are more familiar based on company history. So canonical names can be programmatically consistent, but teams can use other conventions that make more sense in their business context.

Would the aliases be defined in the stack configuration?

components:
  terraform:
    s3-bucket/test:
      settings:
        aliases:
        - dev-01
        - dev-icons
      vars:
        # Canonical stack slug is ue1-dev-assets
        namespace: ue1
        stage: dev
        name: assets

Could be executed in the following ways:

# Using the canonical stack slug `ue1-dev-assets`
atmos terraform plan s3-bucket/test --stack ue1-dev-assets

# For "historical reasons", devs call it "dev-icons"
atmos terraform plan s3-bucket/test --stack dev-icons
osterman commented 7 months ago

I could see aliases being only valid in the settings block being ignored from all imports, because an alias would never be relative to it's stack context.